TLS termination with Ingress in Kubernetes - Commands & Configuration

Introduction

When you want to secure your website or app with HTTPS, TLS termination with Ingress lets the Ingress controller handle the encryption and decryption. This means your backend services get plain HTTP traffic, while users connect securely.

When you want to provide HTTPS access to your Kubernetes services without configuring TLS on each service.

When you want to centralize SSL certificate management in one place for multiple services.

When you want to offload the CPU-intensive TLS encryption from your backend pods.

When you want to use a trusted certificate from a certificate authority for your domain.

When you want to simplify your app deployment by handling TLS at the Ingress level.

Config File - ingress.yaml

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
  - hosts:
    - example.com
    secretName: example-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

This Ingress resource defines TLS termination for the host example.com. The tls section points to a Kubernetes secret named example-tls that holds the TLS certificate and key. The rules section routes HTTP requests for example.com to the backend service example-service on port 80. The annotation nginx.ingress.kubernetes.io/ssl-redirect: "true" ensures HTTP requests are redirected to HTTPS.

Commands

Create a TLS secret named example-tls in Kubernetes using your certificate and private key files. This secret will be used by the Ingress for TLS termination.

Terminal

kubectl create secret tls example-tls --cert=example.com.crt --key=example.com.key

Expected Output

secret/example-tls created

→

--cert - Path to the TLS certificate file

→

--key - Path to the TLS private key file

Apply the Ingress resource that configures TLS termination and routes traffic to your backend service.

Terminal

kubectl apply -f ingress.yaml

Expected Output

ingress.networking.k8s.io/example-ingress created

Check the status of the Ingress resource to confirm it is created and has an address assigned.

Terminal

kubectl get ingress example-ingress

Expected Output

NAME              CLASS    HOSTS          ADDRESS          PORTS     AGE

example-ingress   <none>   example.com    192.168.99.100   80,443    10s

Test the HTTPS connection to your domain to verify TLS termination is working and the certificate is served.

Terminal

curl -I https://example.com

Expected Output

HTTP/1.1 200 OK

Server: nginx/1.21.0

Date: Thu, 01 Jun 2023 12:00:00 GMT

Content-Type: text/html

Content-Length: 612

Connection: keep-alive

→

-I - Fetch only HTTP headers to check response status

Key Concept

If you remember nothing else from this pattern, remember: TLS termination at the Ingress lets your cluster handle HTTPS securely while your backend services use simple HTTP.

Common Mistakes

Not creating the TLS secret before applying the Ingress resource

The Ingress controller cannot find the certificate and key, so TLS termination fails and HTTPS won't work.

Always create the TLS secret with your certificate and key before applying the Ingress that references it.

Using the wrong secret name in the Ingress tls section

The Ingress controller looks for a secret that does not exist, so TLS termination fails.

Make sure the secretName in the Ingress matches exactly the name of the TLS secret you created.

Not adding the ssl-redirect annotation to redirect HTTP to HTTPS

Users can still access the site over insecure HTTP, which defeats the purpose of TLS termination.

Add the annotation nginx.ingress.kubernetes.io/ssl-redirect: "true" to force HTTPS.

Summary

Create a TLS secret in Kubernetes with your certificate and private key.

Apply an Ingress resource that references the TLS secret and routes traffic to your backend service.

Verify the Ingress is created and has an external address.

Test HTTPS access to confirm TLS termination is working.

Practice

1. What is the main purpose of TLS termination in a Kubernetes Ingress?

easy

A. To monitor network traffic for security threats

B. To encrypt traffic between backend services

C. To generate TLS certificates automatically

D. To decrypt HTTPS traffic at the Ingress before forwarding to backend services

Solution

1. Step 1: Understand TLS termination role

   TLS termination means decrypting encrypted HTTPS traffic at a central point.

2. Step 2: Identify Ingress function

   Kubernetes Ingress can handle TLS termination by decrypting traffic before sending it to backend pods.

3. Final Answer:

   To decrypt HTTPS traffic at the Ingress before forwarding to backend services -> Option D

4. Quick Check:

   TLS termination = decrypt at Ingress [OK]

Hint: TLS termination means decrypting at Ingress, not backend [OK]

Common Mistakes:

• Confusing TLS termination with encryption between services
• Thinking Ingress generates certificates automatically
• Assuming TLS termination monitors traffic

2. Which of the following is the correct way to specify TLS in a Kubernetes Ingress YAML?

easy

A. tls:
- hosts:
- example.com
secret: tls-secret

B. tls:
- hosts:
- example.com
secretName: tls-secret

C. tls:
- host: example.com
secret: tls-secret

D. tls:
hosts: example.com
secretName: tls-secret

Solution

1. Step 1: Review TLS section syntax

   The correct syntax uses a list under tls with hosts as a list and secretName key.

2. Step 2: Compare options

   tls: - hosts: - example.com secretName: tls-secret matches the correct YAML structure with 'secretName' and hosts list.

3. Final Answer:

   tls: - hosts: - example.com secretName: tls-secret -> Option B

4. Quick Check:

   Correct TLS YAML uses secretName and hosts list [OK]

Hint: Use 'secretName' and list under 'hosts' in tls section [OK]

Common Mistakes:

• Using 'secret' instead of 'secretName'
• Not using a list for hosts
• Incorrect indentation or missing dash

3. Given this Ingress snippet:

tls:
  - hosts:
    - myapp.example.com
    secretName: myapp-tls

rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-service
            port:
              number: 80

What happens when a user accesses https://myapp.example.com?

medium

A. The Ingress decrypts TLS and forwards HTTP traffic to myapp-service on port 80

B. The Ingress forwards encrypted TLS traffic directly to myapp-service

C. The Ingress rejects the connection because backend port is 80

D. The Ingress terminates TLS but forwards HTTPS traffic to backend

Solution

1. Step 1: Understand TLS termination in Ingress

   The Ingress uses the secret to decrypt HTTPS traffic for the host.

2. Step 2: Check backend service port and protocol

   The backend service listens on port 80 (HTTP), so decrypted HTTP traffic is forwarded.

3. Final Answer:

   The Ingress decrypts TLS and forwards HTTP traffic to myapp-service on port 80 -> Option A

4. Quick Check:

   Ingress decrypts TLS, backend gets HTTP [OK]

Hint: Ingress decrypts TLS, backend usually gets HTTP on port 80 [OK]

Common Mistakes:

• Assuming backend receives encrypted traffic
• Thinking backend must use HTTPS port
• Confusing TLS termination with passthrough

4. You configured TLS in your Ingress but HTTPS requests fail with a certificate error. What is the most likely cause?

medium

A. The secret referenced in tls section does not contain a valid TLS certificate

B. The backend service is not listening on port 443

C. The Ingress controller does not support TLS termination

D. The Ingress resource is missing the rules section

Solution

1. Step 1: Check TLS secret validity

   If the secret does not have a valid TLS cert and key, HTTPS will fail with certificate errors.

2. Step 2: Verify other options

   Backend port or missing rules do not cause cert errors; controller usually supports TLS.

3. Final Answer:

   The secret referenced in tls section does not contain a valid TLS certificate -> Option A

4. Quick Check:

   Invalid TLS secret = cert error [OK]

Hint: Check TLS secret contents first for certificate errors [OK]

Common Mistakes:

• Blaming backend port for TLS cert errors
• Assuming Ingress controller lacks TLS support
• Ignoring TLS secret correctness

5. You want to secure multiple domains with TLS termination using a single Ingress resource. Which approach is correct?

hard

A. Use one tls entry with multiple hosts but different secrets for each host

B. Create separate Ingress resources for each domain with their own TLS secrets

C. Add multiple entries under the tls section with hosts and a single secret containing SAN certificates

D. Configure TLS only on backend services, not on Ingress

Solution

1. Step 1: Understand TLS with multiple hosts

   A single secret can contain a certificate with multiple Subject Alternative Names (SANs) for multiple domains.

2. Step 2: Configure Ingress tls section

   The tls field is a list, so add multiple entries under tls, each with a hosts list and referencing the same secretName containing the SAN cert.

3. Final Answer:

   Add multiple entries under the tls section with hosts and a single secret containing SAN certificates -> Option C

4. Quick Check:

   Multiple tls entries share SAN secret [OK]

Hint: Multiple tls entries can share one SAN cert secret [OK]

Common Mistakes:

• Trying different secrets for each host in one tls entry
• Creating many Ingress resources unnecessarily
• Not using SAN certificates for multiple domains