Kubernetes Ingress Controller, NGINX, TLS, SSL, Let’s Encrypt, cert-manager and ClusterIssuer, HTTPS
https://www.hinty.com.ng/ you can visit here so see the actual site with the Kubernetes Ingress Controller, NGINX, TLS, SSL, Let’s Encrypt, cert-manager and ClusterIssuer active and done thanks for checking this out 😏
When you deploy an application to Kubernetes, you eventually need to answer a simple question:
How does a user on the internet reach my application?
For example, if someone visits:
https://www.hinty.com.ng/
the request might travel through:
Internet
↓
DNS
↓
Load Balancer
↓
NGINX Ingress Controller
↓
Kubernetes Ingress
↓
Service
↓
PodBut then another question appears:
How do we make that connection HTTPS?
This is where TLS, certificates, Let’s Encrypt, cert-manager and ClusterIssuer come together.
What Is Kubernetes Ingress?
An Ingress is a Kubernetes API resource that defines how external HTTP/HTTPS traffic should be routed to Services inside the cluster.
For example:
myapp.com
↓
Ingress
↓
myapp-service
↓
myapp-podThe important thing to understand is:
Ingress is the configuration. It is not the component actually processing the traffic.
Something has to read the Ingress resource and implement those rules.
That’s the job of an Ingress Controller.
What Is NGINX Ingress Controller?
One popular implementation has been the NGINX Ingress Controller.
It watches Kubernetes Ingress resources and configures NGINX to handle incoming HTTP/HTTPS traffic.
The relationship is:
Ingress Resource
↓
NGINX Ingress Controller
↓
NGINX
↓
Kubernetes Service
↓
PodFor example, your Ingress might say:
If the host is:api.myapp.comsend traffic to:api-service:80
The NGINX Ingress Controller reads that configuration and handles the routing.
The controller can be installed using Helm or Kubernetes manifests.
Now Let’s Talk About SSL and TLS
You will often hear people say:
“We need an SSL certificate.”
Technically, modern HTTPS uses TLS (Transport Layer Security).
SSL is the older protocol that TLS replaced.
So when someone says:
“SSL certificate”
they normally mean:
TLS certificate used for HTTPS.
TLS provides encryption between the client and the endpoint terminating TLS and allows the client to verify the server’s identity through the certificate.
What Happens When Someone Visits HTTPS?
Suppose a user enters:
https://myapp.comThe browser connects to the server and starts a TLS handshake.
Very simply:
Browser
↓
"I want a secure connection"
↓
Server
↓
"Here is my certificate"
↓
Browser verifies certificate
↓
TLS handshake
↓
Encrypted HTTPS connectionAfter the handshake succeeds, application traffic can travel through the encrypted connection.
Where Does the Certificate Come From?
This is where Let’s Encrypt comes in.
Let’s Encrypt is a Certificate Authority (CA) that can issue publicly trusted TLS certificates.
But manually managing certificates would be painful.
You would have to:
Request certificate
↓
Install certificate
↓
Configure server
↓
Monitor expiration
↓
Renew certificate
↓
Replace certificateThis is where cert-manager becomes extremely useful.
What Is cert-manager?
cert-manager is a Kubernetes certificate management system.
It can request certificates from certificate authorities such as Let’s Encrypt and manage their lifecycle, including renewal.
The architecture looks like:
Kubernetes
|
↓
cert-manager
|
↓
Let's Encrypt
|
↓
TLS Certificate
|
↓
Kubernetes SecretSo instead of manually managing certificates, Kubernetes can automate much of the process.
What Is a ClusterIssuer?
This is one of the most important parts.
A ClusterIssuer tells cert-manager how certificates should be obtained.
For example:
ClusterIssuer
|
↓
Let's Encrypt
|
↓
HTTP-01 challenge
|
↓
CertificateThe word Cluster matters.
An Issuer is namespace-scoped.
A ClusterIssuer is cluster-scoped and can be referenced by Ingress resources across namespaces.
Get Itojedollars’s stories in your inbox
Join Medium for free to get updates from this writer.
So you might create:
letsencrypt-prodas your ClusterIssuer and then reference it from different application namespaces.
How Does Let’s Encrypt Know You Own the Domain?
Let’s Encrypt doesn’t simply give anyone a certificate for myapp.com.
It needs to verify control of the domain.
One common method is the HTTP-01 challenge.
The flow looks like:
cert-manager
|
↓
Let's Encrypt
|
| "Prove you control myapp.com"
↓
HTTP Challenge
|
↓
http://myapp.com/.well-known/acme-challenge/...
|
↓
NGINX Ingress Controller
|
↓
Temporary challenge endpointLet’s Encrypt checks that URL.
If the expected challenge response is available, the domain is validated.
cert-manager can create the temporary resources needed for this HTTP-01 challenge and route them through the configured Ingress Controller.
How Does cert-manager Know Which Ingress Controller to Use?
This is important when using NGINX.
The ClusterIssuer can specify:
solvers:
- http01:
ingress:
ingressClassName: nginxThat tells cert-manager:
“Use the NGINX Ingress Controller for the HTTP-01 challenge.”
The ingressClassName is important when your cluster has multiple Ingress Controllers.
The Ingress Connects Everything Together
Your application Ingress can reference the ClusterIssuer.
Conceptually:
Ingress
|
| cert-manager.io/cluster-issuer
↓
letsencrypt-prodAnd your TLS configuration specifies where the certificate should be stored:
TLS
├── Host: myapp.com
└── Secret: myapp-tlscert-manager watches the Ingress and can create the corresponding Certificate resource and TLS Secret.
The Secret ultimately contains:
myapp-tls
├── tls.crt
└── tls.keyKubernetes uses this TLS Secret for the certificate and private key.
The Complete Flow
Now we can put everything together.
A user visits:
https://myapp.com1. DNS
The domain points to the external endpoint of the Ingress Controller.
myapp.com
↓
Load Balancer2. HTTPS
The browser connects over:
HTTPS :4433. NGINX Ingress Controller
NGINX receives the request.
Browser
↓
HTTPS :443
↓
NGINX Ingress Controller4. TLS Termination
NGINX can terminate TLS using the certificate stored in the Kubernetes Secret.
Browser
|
| Encrypted HTTPS
↓
NGINX
|
| TLS termination
↓
Kubernetes ServiceKubernetes Ingress TLS configuration references a Secret containing tls.crt and tls.key; the standard Ingress model assumes TLS termination at the ingress point.
5. Ingress Routing
NGINX reads the Ingress rules:
myapp.com
↓
myapp-service6. Service
The Service selects the appropriate Pods.
myapp-service
|
┌──┴──┐
↓ ↓
Pod 1 Pod 27. Application
Finally, the request reaches the application.
The Architecture
This is the mental model I keep in mind:
INTERNET
|
|
https://myapp.com
|
↓
DNS
|
↓
Load Balancer
|
↓
NGINX Ingress Controller
|
TLS TERMINATION
|
↓
Kubernetes Ingress
|
↓
Kubernetes Service
|
┌──────┴──────┐
↓ ↓
Pod 1 Pod 2And alongside it:
cert-manager
|
↓
ClusterIssuer
|
↓
Let's Encrypt
|
HTTP-01 Challenge
|
↓
TLS Certificate
|
↓
Kubernetes TLS Secret
|
↓
NGINX Ingress ControllerThe Big Picture
So when you see these technologies together:
Kubernetes Ingress
defines how traffic should be routed.
NGINX Ingress Controller
actually implements those routing rules.
TLS
provides secure encrypted communication.
Certificate
allows the client to verify the server’s identity and establish TLS.
Let’s Encrypt
acts as the public Certificate Authority issuing the certificate.
cert-manager
automates requesting, storing, and renewing certificates.
ClusterIssuer
defines how cert-manager should obtain certificates at the cluster level.
And finally:
Browser
↓
HTTPS
↓
Load Balancer
↓
NGINX Ingress Controller
↓
Ingress
↓
Service
↓
Podwhile cert-manager handles the certificate lifecycle in the background.
That is the real relationship between Ingress, NGINX, TLS, SSL, Let’s Encrypt, cert-manager and ClusterIssuer in a Kubernetes environment.
