Sign in Subscribe
Kubernetes

End-to-End Kubernetes Auth, DNS, and TLS with Helmfile

Mark Allen

• 2 min read

One of the recurring themes in Kubernetes operations is automation of the boring but critical stuff, TLS certificates, DNS records, and user authentication.

In earlier articles, we walked through the steps individually:

This article stitches those pieces together into a unified workflow. With a single helmfile apply, you’ll get:

  • Ingress-NGINX running as your ingress controller
  • cert-manager + Cloudflare DNS-01 ClusterIssuer for Let’s Encrypt certificates
  • ExternalDNS creating DNS records automatically in Cloudflare for each ingress
  • oauth2-proxy providing Google login at login.<domain>
  • An whoami app with HTTPS, DNS, and authentication, all wired together automatically

Why Helmfile?

Helm charts are great for packaging, but when you need to install multiple interdependent components with consistent values, Helmfile shines. It lets you define all releases in one YAML, share global values, and apply everything in one go.

The Flow

Here’s how the pieces interact when a user requests https://whoami.example.com:

flowchart TD U[User Browser] -->|Request whoami.example.com| NGINX[NGINX Ingress Controller] NGINX -->|auth-url annotation| O2P[oauth2-proxy @ login.example.com] O2P -->|Redirect if not logged in| Google[Google OAuth2] Google -->|Callback| O2P O2P -->|Sets cookie & returns| NGINX NGINX -->|Proxy traffic| App[Whoami Example Deployment] subgraph cert-manager CM[ClusterIssuer Cloudflare DNS-01] end subgraph external-dns ED[Watches Ingress, creates DNS in Cloudflare] end NGINX -.-> CM NGINX -.-> ED
  • cert-manager ensures TLS certificates are always valid, solving ACME challenges via Cloudflare.
  • external-dns watches Ingress resources and updates DNS records in Cloudflare.
  • oauth2-proxy enforces Google login before traffic reaches the app.

Installing the Stack

Clone the repo (we generated it earlier in this chat):

git clone https://github.com/markcallen/auth-tls
cd auth-tls

Edit default.yaml to set your domain and secrets:

adminEmail: "mark@example.com"
cloudflareApiToken: ""
domainName: "example.com"
oauth2:
  googleClientID: ""
  googleClientSecret: ""
  cookieSecret: "$(openssl rand -base64 32 | tr -d '\n' | tr '+/' '-_')"

Apply everything:

helmfile apply

That installs:

  • ingress-nginx (Ingress controller)
  • cert-manager (TLS with DNS-01 solver)
  • external-dns (DNS automation with Cloudflare)
  • oauth2-proxy (Google login at login.<domain>)
  • whoami-example (protected by oauth2-proxy, with HTTPS and DNS)

Testing the Flow

  1. Navigate to https://whoami.example.com.
  2. You’ll be redirected to https://login.example.com (oauth2-proxy).
  3. oauth2-proxy forwards you to Google for authentication.
  4. On success, you’re redirected back to your app, authenticated and secured over TLS.

Pro Tips

  • Store secrets in environment variables and use Helmfile’s templating to avoid committing them in default.yaml.
  • Reuse the same global cluster issuer (global.clusterIssuer) across multiple services.

Wrapping Up

Instead of piecing things together by hand, you now have a repeatable, one-command setup for Kubernetes apps that require TLS, DNS, and Google login.

This pattern scales: just add more app Helm releases, and they’ll automatically get certs, DNS records, and login protection.

👉 Next steps: try applying this workflow to one of your internal services. Replace the whoami-example with your real workloads and watch the automation handle the rest.