Securing Dgraph /admin route

I created this in response to a question, and I thought others may be interested in this content.

1. Community Version: Shared Secret Token

There’s a shared secret token (X-Dgraph-AuthToken) that can be used to secure access. For security best practices, this shared secret should be rotated, which will mean relaunching Dgraph to update the new shared secret, as well as re-configuring clients to use the secret.

2. Enterprise Version: Access Control Lists

Dgraph supports using a JWT token (X-Dgraph-AccessToken) that requires logging into an account that you set up within Dgraph. The client will receive an access token and an refresh token after logging in. The refresh token can be used to continue the session after the initial token expires. The gRPC clients (Java, Go, Python, JavaScript, DotNet) will handle the session management, should you want to use these clients on those platforms.

In order to enable this feature, you need to configure ACLs, where you will save a secret only known to the Dgraph server. This secret can be saved externally to a Hashicorp Vault service.

As part of the setup, I recommend not using the root account (groot) and setting up an account for administrative purposes, by adding it to the Guardians group, and another account for non-administrative access, that is not a member of the Guardians group.

3. All Versions

3.1 Dgraph White List

Dgraph requires configuring a whitelist, which can be everything, or a more restrictive list of systems.

3.2 Dgraph in coordination with external ingresses/service-meshes/network-policy

Outside of Dgraph, you can also configure a reverse-proxy load balancer or a service mesh that can further restrict routes like /admin. We have had customers use nginx, Traefik, and other reverse proxies (ingress controllers in Kubernetes), as well as service meshes like Linkerd and Istio.

One advantage to using these technologies to work beside Dgraph is using TLS, terminated at the Layer 7 LB with reverse-proxy ingress controllers, or with service meshes like Istio and Linkerd, terminated at the side car running besides Dgraph containers. It is easier to terminate encryption using these external services, than configure it directly with Dgraph.

For both of these scenarios, I recommend using a network proxy like Calico to further secure internal traffic form other namespaces, so that only permitted traffic is allowed through.

For administrative traffic, you could restrict traffic for administrative routes to an internal loadbalancer or gateway, which could then further be accessed through a VPN or jump/bastion host.