TLS termination with Ingress in Kubernetes - Mini Project: Build & Apply

TLS termination with Ingress

📖 Scenario: You are setting up a simple web application on Kubernetes. You want to secure your website by enabling HTTPS using TLS termination at the Ingress controller. This means the Ingress will handle the encryption and decryption of traffic, so your backend pods receive plain HTTP traffic.

🎯 Goal: Learn how to configure TLS termination on a Kubernetes Ingress resource by creating a TLS secret and referencing it in the Ingress configuration.

📋 What You'll Learn

Create a TLS secret with a certificate and private key

Create an Ingress resource that uses the TLS secret for HTTPS

Configure the Ingress to route traffic to a backend service

Verify that the Ingress is correctly set up for TLS termination

💡 Why This Matters

🌍 Real World

In real Kubernetes deployments, TLS termination at the Ingress controller secures web traffic by encrypting data between users and the cluster. This is a common practice for production web applications.

💼 Career

Understanding TLS termination with Ingress is essential for DevOps engineers and site reliability engineers who manage secure Kubernetes environments and ensure safe communication for applications.

1

Create a TLS secret

Create a TLS secret named my-tls-secret in the default namespace using the certificate file tls.crt and the private key file tls.key. Use the kubectl create secret tls command exactly as shown.

Kubernetes

# Your code here

Hint

Use the kubectl create secret tls command with the exact secret name my-tls-secret and specify the certificate and key files.

2

Create a basic Ingress resource with TLS

Create a YAML file named ingress.yaml that defines an Ingress resource named my-ingress in the default namespace. Add a tls section that references the secret my-tls-secret and sets the host to example.com. Under rules, add a rule for host example.com that routes HTTP traffic to the service named my-service on port 80. Use the exact keys and names as specified.

Kubernetes

kubectl create secret tls my-tls-secret --cert=tls.crt --key=tls.key
# Write the ingress.yaml content below
# Your code here

Hint

Remember to add the tls section with hosts and secretName. Then add a rules section with the host and backend service details.

3

Apply the Ingress resource

Use the kubectl apply -f ingress.yaml command to create the Ingress resource in the cluster.

Kubernetes

kubectl create secret tls my-tls-secret --cert=tls.crt --key=tls.key

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: default
spec:
  tls:
  - hosts:
    - example.com
    secretName: my-tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

# Your code here

Hint

Use kubectl apply -f ingress.yaml to create or update the Ingress resource.

4

Verify the Ingress TLS setup

Run kubectl describe ingress my-ingress and check the output to confirm that the TLS section shows the secret my-tls-secret and the host example.com. Then print the output exactly as shown.

Kubernetes

kubectl create secret tls my-tls-secret --cert=tls.crt --key=tls.key

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: default
spec:
  tls:
  - hosts:
    - example.com
    secretName: my-tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

kubectl apply -f ingress.yaml

# Your code here

Hint

Use kubectl describe ingress my-ingress and look for the TLS secret and host in the output.

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