Ingress TLS Termination: Encrypting at the Front Door
The cluster's front door terminates TLS: it accepts encrypted HTTPS, decrypts it right there, and forwards plain HTTP inside. One-way only, and the cert is automated.
Setup: the services here run on Kubernetes, a platform that runs many small services. In front of them sits the ingress, the cluster’s front door that receives outside web traffic and routes it to the right service.
That front door terminates TLS: it accepts the visitor’s encrypted HTTPS, decrypts it right there, and forwards plain HTTP to the service behind it (say on port 8000). The internal network is treated as trusted, so traffic past the front door is usually left unencrypted.
Two things define it:
- One-way TLS only. The front door shows a server certificate. Visitors are not asked to hold one.
- The server certificate is automated. A small annotation hands the job to a certificate-automation tool, which requests the certificate from a CA, stores it, and renews it before it expires. The front door reads it and serves HTTPS. Nobody rotates it by hand.
The direction is the thing to hold onto: this protects traffic coming into the service. It says nothing about the service’s outbound connections to anything else.
In this migration: the front-door HTTPS was already set up this way, and the Kafka work did not touch it. That is the classic mix-up of two “SSL”s pointing opposite ways: the front door strips encryption on the way in, and Kafka adds it on the way out.
“The service already has SSL” and “the service needs SSL” can both be true, because they point in opposite directions.
References
- https://cert-manager.io/docs/usage/ingress/
- https://kindatechnical.com/kubernetes-fundamentals/lesson-54-tls-termination-securing-ingress-with-certificates-and-cert-manager.html
Related: the front door runs one-way TLS (the opposite direction from Kafka’s mutual TLS), and its automated cert is delivered like the ones in certs to a pod. Back to the overview: two SSLs behind one migration ticket.