TLS Certificates

Overview

Terraform installed cert-manager in the GKE cluster, which automates TLS certificate issuance and renewal. In this step, you will:

• Understand how TLS works with NGINX Ingress and cert-manager on GCP
• Configure a cert-manager ClusterIssuer for certificate provisioning
• Verify cert-manager is operational
• Prepare for ingress TLS configuration in later steps

Unlike AWS (which uses ACM), GCP deployments use cert-manager with Let’s Encrypt or your organization’s certificate authority.

How TLS works on GCP

The GCP deployment uses a different TLS approach than AWS:

1. NGINX Ingress Controller handles TLS termination (instead of ALB)
2. cert-manager automates certificate requests and renewals
3. Let’s Encrypt (or your CA) issues the certificates
4. Certificates are stored as Kubernetes Secrets

When a user connects to your domain:

1. DNS resolves to the GCP Network Load Balancer IP
2. Load Balancer forwards traffic to NGINX Ingress
3. NGINX terminates TLS using the certificate from the Kubernetes Secret
4. NGINX routes the request to the appropriate backend service

Verify cert-manager is running

cert-manager was installed by Terraform via Helm. Verify it’s operational:

$
kubectl get pods -n cert-manager

Expected output:

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-xxx-yyy                       1/1     Running   0          30m
cert-manager-cainjector-xxx-yyy            1/1     Running   0          30m
cert-manager-webhook-xxx-yyy               1/1     Running   0          30m

All three pods should be Running.

$
terraform apply

Configure a ClusterIssuer

A ClusterIssuer tells cert-manager how to obtain certificates. The most common option is Let’s Encrypt.

Option A: Let’s Encrypt (recommended for internet-facing)

Create a file cluster-issuer.yaml:

1
apiVersion: cert-manager.io/v1
2
kind: ClusterIssuer
3
metadata:
4
  name: letsencrypt-prod
5
spec:
6
  acme:
7
    server: https://acme-v02.api.letsencrypt.org/directory
8
    email: your-email@yourdomain.com
9
    privateKeySecretRef:
10
      name: letsencrypt-prod-key
11
    solvers:
12
      - http01:
13
          ingress:
14
            class: nginx

Apply it:

$
kubectl apply -f cluster-issuer.yaml

Verify the issuer is ready:

$
kubectl get clusterissuer letsencrypt-prod

Expected output:

NAME               READY   AGE
letsencrypt-prod   True    30s

Option B: Internal CA or self-signed (for private clusters)

If your ingress is internal (not internet-facing), you can’t use Let’s Encrypt. Options:

1. Corporate CA: Work with your PKI team to issue certificates and create Kubernetes TLS secrets manually
2. Self-signed: Use cert-manager’s self-signed issuer (browsers will show warnings)

Self-signed issuer example:

1
apiVersion: cert-manager.io/v1
2
kind: ClusterIssuer
3
metadata:
4
  name: selfsigned-issuer
5
spec:
6
  selfSigned: {}

DNS preparation

Before certificates can be issued, your DNS must point to the NGINX Ingress load balancer. You’ll configure this fully during the Verification step, but you can check the load balancer IP now:

$
kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

This returns the GCP Network Load Balancer IP that your DNS records should point to.

Next steps

After cert-manager is operational and a ClusterIssuer is configured, proceed to Cluster Access to configure kubectl access and verify infrastructure components.