Day 69: In-cluster TLS
Encrypting traffic inside the cluster, not just at the edge
It's tempting to assume traffic *inside* the cluster is automatically safe since it never leaves your infrastructure — but a compromised Pod or a misconfigured NetworkPolicy can still let an attacker sniff unencrypted internal traffic. In-cluster TLS applies the same handshake/certificate concepts from Phase 2, Day 21 to Service-to-Service communication.
cert-manager is the standard tool for this: it automates issuing and renewing TLS certificates for in-cluster services (and Ingress endpoints), talking to a CA — including Let's Encrypt for public-facing Ingress, or your own internal CA for service-to-service certs — the same short-lived, auto-renewed philosophy as Let's Encrypt itself.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: api-tls
spec:
secretName: api-tls-secret
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- api.example.comThis is exactly what a service mesh automates further
Manually configuring cert-manager for every service-to-service connection gets unwieldy fast — Phase 22's service mesh automates mutual TLS (mTLS) between every Pod transparently, which is one of the strongest arguments for adopting a mesh at scale.
The Four Questions: cert-manager (or RBAC)
Worked example for Docker: dependency hell → consistent runtime environments → VMs too heavy → shared kernel, weaker isolation. Apply it to cert-manager: what problem (manual cert issuance/renewal at scale) did it solve, why couldn't manual cert management scale, and what trade-off (another controller to operate and trust) does it introduce?
Key terms
- cert-manager
- Automates issuing and renewing TLS certificates for in-cluster and Ingress use.
Phase 11 complete — you should now be able to
Why is unencrypted in-cluster traffic a real risk even though it never crosses the public internet?
