# Dgraph on GKE w CertManager + ExternalDNS

**URL:** <https://discuss.dgraph.io/t/dgraph-on-gke-w-certmanager-externaldns/17704>\
**Category:** Dgraph\
**Tags:** area:kubernetes\
**Created:** [August 29, 2022, 5:17pm UTC](https://discuss.dgraph.io/t/dgraph-on-gke-w-certmanager-externaldns/17704 "2022-08-29T17:17:00Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![joaquin](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/joaquin/32/2619_2.png) [@joaquin](https://discuss.dgraph.io/u/joaquin)\
**Post date:** [August 29, 2022, 5:17pm UTC](https://discuss.dgraph.io/t/dgraph-on-gke-w-certmanager-externaldns/17704/1 "2022-08-29T17:17:00Z")

</div>

Recently, I wrote a blog over the weekend about how [CertManager](https://cert-manager.io/) and [ExternalDNS](https://github.com/kubernetes-sigs/external-dns) to automatically configure DNS records and issue trusted certificates for endpoints, with Dgraph as the example application of course for this.

As writing DNS records should be restricted, I show how to do this more securely with [Workload Identity](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity), which uses [OpenID Connect](https://openid.net/connect/). Some of this complexity is hidden through automation with [Helmfile](https://github.com/helmfile/helmfile).

[Dgraph Ratel](https://dgraph.io/docs/v21.03/ratel/overview/) was put into a separate namespace, as this will allow for more secure settings when network policies like [Calico](https://projectcalico.docs.tigera.io) or [Cillium](https://cilium.io/) or service meshes with strict mode like [NSM](https://www.nginx.com/products/nginx-service-mesh/) are used.

> **[GKE with CertManager](https://joachim8675309.medium.com/gke-with-certmanager-9bc00b086b73)**
>
> Using cert-manager add-on with GKE