Ingress annotations for customization in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Ingress Annotations

What is the primary purpose of using annotations in a Kubernetes Ingress resource?

A To define the backend services for the Ingress rules

B To customize the behavior of the Ingress controller without changing the Ingress spec

C To specify the namespace where the Ingress is deployed

D To create persistent storage for the Ingress resource

💡 Hint

Think about how you can change settings like SSL or timeouts without modifying the main rules.

Annotations allow you to add extra configuration to the Ingress controller, such as SSL settings, timeouts, or rewrite rules, without altering the core Ingress specification.

💻 Command Output

intermediate

Output of Ingress with SSL Redirect Annotation

Given this Ingress snippet with annotation nginx.ingress.kubernetes.io/ssl-redirect: "true", what effect does this have on HTTP requests?

Kubernetes

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

A All HTTP requests are redirected to HTTPS automatically

B HTTP requests are blocked and return 403 Forbidden

C HTTP requests are served normally without redirection

D Ingress controller disables HTTPS for this host

💡 Hint

Consider what 'ssl-redirect: true' means for incoming traffic.

The annotation nginx.ingress.kubernetes.io/ssl-redirect: "true" tells the NGINX Ingress controller to redirect all HTTP requests to HTTPS automatically.

❓ Configuration

advanced

Correct Annotation for Custom Timeout

You want to set a custom proxy read timeout of 120 seconds on an NGINX Ingress. Which annotation correctly sets this timeout?

A nginx.ingress.kubernetes.io/proxy-read-timeout: "120"

B nginx.ingress.kubernetes.io/proxy-read-timeout-seconds: "120"

C nginx.ingress.kubernetes.io/proxy-timeout: "120"

D nginx.ingress.kubernetes.io/proxy-read-timeout-ms: "120000"

💡 Hint

Look for the exact annotation name used by NGINX Ingress for read timeout.

The correct annotation to set the proxy read timeout in seconds is nginx.ingress.kubernetes.io/proxy-read-timeout. The value is in seconds as a string.

❓ Troubleshoot

advanced

Why is the Rewrite Annotation Not Working?

You added the annotation nginx.ingress.kubernetes.io/rewrite-target: / to your Ingress, but the URL paths are not rewritten as expected. What is a common cause?

A The annotation value must be a full URL, not just '/'

B The backend service must be named 'rewrite-service' for this to work

C Rewrite annotation only works with HTTP, not HTTPS

D The Ingress path is not defined with a regex pathType

💡 Hint

Check the pathType used in the Ingress rule when using rewrite-target.

The rewrite-target annotation requires the Ingress path to be defined as a regex pathType to match and rewrite the URL path correctly.

✅ Best Practice

expert

Best Practice for Securing Ingress with Annotations

Which annotation combination is best practice to enhance security by enabling HTTP Strict Transport Security (HSTS) with a max age of 6 months and including subdomains on an NGINX Ingress?

A

nginx.ingress.kubernetes.io/hsts: "enabled"
nginx.ingress.kubernetes.io/hsts-max-age: "15768000"
nginx.ingress.kubernetes.io/hsts-include-subdomains: "enabled"

B

nginx.ingress.kubernetes.io/hsts: "true"
nginx.ingress.kubernetes.io/hsts-max-age: "15768000"
nginx.ingress.kubernetes.io/hsts-include-subdomains: "true"

C nginx.ingress.kubernetes.io/configuration-snippet: 'add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;'

D

nginx.ingress.kubernetes.io/enable-hsts: "yes"
nginx.ingress.kubernetes.io/hsts-duration: "15768000"
nginx.ingress.kubernetes.io/hsts-subdomains: "yes"

💡 Hint

NGINX Ingress does not have built-in hsts annotations; custom headers are added via configuration-snippet.

NGINX Ingress does not support dedicated HSTS annotations. The best practice is to add the HSTS header using the configuration-snippet annotation with the correct header syntax.

Practice

1. What is the main purpose of using annotations in a Kubernetes Ingress resource?

easy

A. To specify the IP address of the Ingress controller

B. To define the backend services for routing traffic

C. To customize the behavior of the Ingress controller without changing the main spec

D. To set resource limits for the Ingress pod

Solution

1. Step 1: Understand the role of annotations in Kubernetes

   Annotations are key-value pairs used to add metadata or customize behavior without changing the main resource spec.

2. Step 2: Apply this to Ingress resources

   In Ingress, annotations allow customization of controller behavior like SSL settings or rewrite rules without modifying the core routing rules.

3. Final Answer:

   To customize the behavior of the Ingress controller without changing the main spec -> Option C

4. Quick Check:

   Ingress annotations = customization without spec change [OK]

Hint: Annotations customize Ingress behavior without touching main config [OK]

Common Mistakes:

• Confusing annotations with service definitions
• Thinking annotations set IP addresses
• Assuming annotations control pod resources

2. Which of the following is the correct syntax to add an annotation for enabling SSL redirect in a Kubernetes Ingress YAML?

easy

A. metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"

B. spec:
annotations:
ssl-redirect: true

C. metadata:
labels:
nginx.ingress.kubernetes.io/ssl-redirect: true

D. annotations:
ssl-redirect: "true"

Solution

1. Step 1: Locate where annotations belong in Ingress YAML

   Annotations must be under metadata.annotations as key-value pairs.

2. Step 2: Check correct key and value format

   The key for SSL redirect in nginx ingress is nginx.ingress.kubernetes.io/ssl-redirect and the value should be a string "true".

3. Final Answer:

   metadata: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true" -> Option A

4. Quick Check:

   Annotations under metadata.annotations with string values [OK]

Hint: Annotations go under metadata.annotations as string key-values [OK]

Common Mistakes:

• Placing annotations under spec instead of metadata
• Using labels instead of annotations
• Using boolean true instead of string "true"

3. Given this Ingress snippet with annotations:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/"
    nginx.ingress.kubernetes.io/ssl-redirect: "false"

What will be the effect on incoming HTTP requests?

medium

A. Requests will be redirected to HTTPS and paths rewritten to root

B. Requests will not redirect to HTTPS and paths will be rewritten to root

C. Requests will redirect to HTTPS but paths will not be rewritten

D. Requests will neither redirect to HTTPS nor rewrite paths

Solution

1. Step 1: Analyze the ssl-redirect annotation

   The annotation nginx.ingress.kubernetes.io/ssl-redirect: "false" disables automatic HTTP to HTTPS redirection.

2. Step 2: Analyze the rewrite-target annotation

   The annotation nginx.ingress.kubernetes.io/rewrite-target: "/" rewrites the path of incoming requests to root (/).

3. Final Answer:

   Requests will not redirect to HTTPS and paths will be rewritten to root -> Option B

4. Quick Check:

   ssl-redirect false disables HTTPS redirect; rewrite-target "/" rewrites paths [OK]

Hint: ssl-redirect false disables HTTPS redirect; rewrite-target changes path [OK]

Common Mistakes:

• Assuming ssl-redirect false still redirects
• Ignoring rewrite-target effect
• Confusing rewrite-target with redirect

4. You added this annotation to your Ingress:

nginx.ingress.kubernetes.io/ssl-redirect: true

But HTTPS redirection is not working. What is the most likely cause?

medium

A. The annotation value should be a string "true", not boolean true

B. The annotation must be under spec.annotations, not metadata.annotations

C. The Ingress controller does not support this annotation

D. You need to restart the Ingress controller pod

Solution

1. Step 1: Check annotation value type

   Annotations require string values, so boolean true is invalid and ignored.

2. Step 2: Confirm correct placement and support

   The annotation must be under metadata.annotations and nginx ingress supports this annotation.

3. Final Answer:

   The annotation value should be a string "true", not boolean true -> Option A

4. Quick Check:

   Annotation values must be strings, not booleans [OK]

Hint: Annotation values must be strings, not booleans [OK]

Common Mistakes:

• Placing annotations under spec instead of metadata
• Assuming controller restart fixes annotation issues
• Ignoring controller support for annotation

5. You want to customize your Ingress to add a custom header X-Frame-Options: DENY for security. Which annotation and value should you add to achieve this with nginx ingress controller?

hard

A. nginx.ingress.kubernetes.io/custom-header: "X-Frame-Options=DENY"

B. nginx.ingress.kubernetes.io/add-headers: "X-Frame-Options: DENY"

C. nginx.ingress.kubernetes.io/headers: "X-Frame-Options: DENY"

D. nginx.ingress.kubernetes.io/configuration-snippet: "more_set_headers \"X-Frame-Options: DENY\";"

Solution

1. Step 1: Identify how to add custom headers in nginx ingress

   The nginx ingress controller supports adding custom headers via the configuration-snippet annotation using nginx directives.

2. Step 2: Use the correct syntax for setting headers

   The directive more_set_headers "X-Frame-Options: DENY"; correctly adds the header.

3. Final Answer:

   nginx.ingress.kubernetes.io/configuration-snippet: "more_set_headers \"X-Frame-Options: DENY\";" -> Option D

4. Quick Check:

   Use configuration-snippet with more_set_headers for custom headers [OK]

Hint: Use configuration-snippet with nginx directive for custom headers [OK]

Common Mistakes:

• Using non-existent annotation keys
• Incorrect syntax for header setting
• Confusing add-headers with configuration-snippet