Dgraph TLS with the Dgraph helm charts

Users Dgraph
1

@Thulasidhar-Siva There are a variety of different ways to add TLS and some considerations. First some questions:

  • Do you need TLS terminated on the endpoint (load balancer) to the client?
  • Do you need TLS on the Dgraph Alpha service itself? Do you need MutualTLS?
  • Do you need TLS to secure internal traffic as well, i.e. Zeroes and Alphas?

General TLS prerequisites

If you use a public certificate, you will need to have a registered domain or subdomain. In Kubernetes, you can use a Kubernetes add-on like external-dns to automatically add DNS records for Dgraph endpoints. This can configure AWS Route53, Google CloudDNS, and many others. Otherwise, you can use a private certificate.

TLS terminated at the endpoint

On Kubernetes, you can use certificate solutions from the cloud provider or use the Kubernetes add-on cert-manager.

  • ACM (AWS Certificate Manager) - for use with either service type of LoadBalancer configured as Layer 7.
  • Google Cloud Managed SSL - for use with ingress resource using ingress type of gce.
  • cert-manager (Kubernetes add-on) for use with ingress resource

EndPoints with Kubernetes

For endpoints with Kubernetes, you want to use either service of LoadBalancer type or an ingress. These can be used when configuring the option in a Dgraph helm chart configuration file, e.g. my-values.yaml:

helm install my-release --values my-values.yaml dgraph/dgraph

You want to set alpha.service.type to LoadBalancer, which will provision a load balancer should your cloud provider supports it. This will have to be a Layer 7 load balancer to support certificates.

For example with AWS ELB, you can configure the load balancer to be Layer 7 by supplying the proper annotations to alpha.service.annotations. On Google Cloud, layer 7 load balancers are only supported with an ingress.

For ingress examples, there are some examples in:

When configuring an endpoint, you will want to secure it. I presented some options for AWS (which will be similar to other cloud providers):

TLS added directly to Dgraph services

For instructions on securing the Dgraph Alpha service and examples, these are in the Helm Chart instructions for MutualTLS:

Here are some links for instructions and examples of configuring TLS for Dgraph Alpha service:

Securing internal traffic

If you need all traffic, including internal traffic between Dgraph Alpha and Zero nodes, you can find instructions here:

More examples with helmfile

I put all this together as an example using helmfile. The helmfile tool is useful in automating helm charts with dynamic values. You can find the example and instructions here:

2

Hi joaquin,

I followed this for my cert generation using scripts.

If in that case, from code side how can i add for .Net Client

one more issue, is there any chance to pass our own(godady) certificates

3

Hello @Thulasidhar-Siva,

DotNet Client

On the topic of dotnet clients, there’s documentation here:

Even though this says C# in our docs, because this runs on CLR VM (Common Language Runtime), this should work with any language on dotnet platform.

GoDaddy Cert/Key

As far as using external certificates, i.e. GoDaddy. The easiest approach for HTTPS wold be to add the certificate to the load balancer and terminate TLS there.

For HTTPS or GRPC (h2) directly to the Dgraph Alpha service w/o terminating at the load balancer, this is how you might be able to do this. You definitely would have to use --tls_use_system_ca when starting Dgraph Alpha. If you can supply the ca.crt and **ca.key**, and generate the web server cert/key with GoDaddy and save these as node.crt and node.key, then this should work.

However, if you do not have the ca.crt and ca.key (which is understandable, as GoDaddy wouldn’t give this out if it is a public trusted cert/key), then you need to generate cert/key saved as node.crt and node.key. You may have to generate a ca.crt and ca.key with dgraph cert command to put in the tls directory, but with --tls_use_system_ca, Dgraph Alpha will check the against public CA certs/keys like GoDaddy.

Lastly, I wanted to mention that the incoming requests with TLS, the client has to use a FQDN that is specified in the certificate or session will be rejected. Thus you will have to make sure than when the client makes a request to the endpoint, the endpoint matches the configured FQDN in the certificate. This can be done when testing out the solution, such as:

  • A or CNAME record to the endpoint configured in a DNS server
  • client configuration, e.g. /etc/hosts, with the endpoint and desired FQDN
  • add Hosts <FQDN> in header when making request
  • curl and adding --resolve <FQDN>:port https://<endpoint> command line flag
4

Hello @joaquin,

When i followed this method:

However, if you do not have the ca.crt and ca.key (which is understandable, as GoDaddy wouldn’t give this out if it is a public trusted cert/key), then you need to generate cert/key saved as node.crt and node.key . You may have to generate a ca.crt and ca.key with dgraph cert command to put in the tls directory, but with --tls_use_system_ca , Dgraph Alpha will check the against public CA certs/keys like GoDaddy.

After rdeploying the helm chart alpha pod is crashing,

image
image807×244 6.77 KB

Logs of alpha:

image
image1886×1008 83.5 KB

This is what happening, But the same procedure is working fine standalone baremetal.
If we deploy using Helm Chart it is the issue.

I feel like while in standalone also faced the same issue first the by using this command “update-ca-certificates” issue resolved.

But how we need to pass this cmd through the helm.

Thanks

5

Any one there? @joaquin @MichelDiz
Can U please look in to the above issue