Introduction

Ingress-wide SSL redirect is useful for security, but sometimes one host must remain on HTTP for legacy integrations or controlled internal traffic. In NGINX Ingress, redirect behavior is mostly annotation-driven, and annotations apply per Ingress resource, not per host rule. The clean workaround is splitting hosts across separate Ingress objects.

Understand Redirect Scope in NGINX Ingress

A common annotation is nginx.ingress.kubernetes.io/ssl-redirect. When set to true, HTTP requests are redirected to HTTPS. The important detail is scope: annotation behavior affects the whole Ingress resource.

If one Ingress contains both secure and non-secure hosts, selective per-host redirect is difficult and often brittle. Splitting into two resources gives explicit control and clearer intent.

Configure Secure and Non-Secure Hosts Separately

Use one Ingress for hosts that must redirect and another for hosts that should stay on HTTP.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: web-secure
5  namespace: app
6  annotations:
7    nginx.ingress.kubernetes.io/ssl-redirect: "true"
8spec:
9  ingressClassName: nginx
10  tls:
11    - hosts:
12        - secure.example.com
13      secretName: secure-example-tls
14  rules:
15    - host: secure.example.com
16      http:
17        paths:
18          - path: /
19            pathType: Prefix
20            backend:
21              service:
22                name: web-service
23                port:
24                  number: 80

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: web-insecure
5  namespace: app
6  annotations:
7    nginx.ingress.kubernetes.io/ssl-redirect: "false"
8spec:
9  ingressClassName: nginx
10  rules:
11    - host: insecure.example.com
12      http:
13        paths:
14          - path: /
15            pathType: Prefix
16            backend:
17              service:
18                name: web-service
19                port:
20                  number: 80

This approach keeps intent explicit and easy to reason about during audits.

Validate Behavior After Deployment

After applying manifests, verify each host independently.

1kubectl apply -f web-secure.yaml
2kubectl apply -f web-insecure.yaml
3
4kubectl get ingress -n app
5
6curl -I http://secure.example.com
7curl -I http://insecure.example.com

Expected result:

• secure.example.com returns redirect status to HTTPS
• insecure.example.com responds directly on HTTP without redirect

If behavior differs, inspect effective NGINX configuration and controller logs.

Optional: Force Redirect on Path Basis With Snippets

Some teams attempt path-level custom rules using snippet annotations. This can work, but it increases operational complexity and may conflict with controller security settings that disable snippets.

Prefer separate Ingress resources first. Use snippets only when architecture constraints make split resources impossible.

Security and Operational Considerations

Hosts excluded from SSL redirect should be intentionally documented and reviewed regularly. If plaintext traffic is allowed, define network boundaries and monitoring expectations clearly.

Recommended controls:

• restrict insecure host exposure with source IP allow lists
• run periodic checks that insecure hosts remain intentional
• log and alert on unexpected traffic patterns
• keep deprecation timeline for legacy HTTP dependencies

Exclusions should be treated as temporary exceptions whenever possible.

Common Pitfalls

• Trying to configure host-specific redirect behavior inside one Ingress resource only.
• Forgetting that annotations usually apply at resource scope, not host-rule scope.
• Defining TLS for an insecure host accidentally, which can trigger redirect side effects.
• Skipping post-deploy verification and assuming annotation changes applied as intended.
• Allowing permanent HTTP exceptions without documented risk ownership.

Summary

• SSL redirect annotations are generally applied per Ingress resource.
• To exclude specific hosts, split secure and non-secure hosts into separate Ingress objects.
• Validate each host with explicit HTTP checks after deployment.
• Use snippet-based overrides only when split resources are not feasible.
• Treat HTTP exceptions as controlled, reviewed risk decisions.
• Keep separate ownership and review approval for insecure-host manifests in production clusters.
• Add continuous HTTP probes to detect accidental redirect policy changes after controller upgrades.
• Use namespace labels and policy checks so insecure ingress resources are easy to inventory.
• Revisit exception necessity regularly and migrate legacy clients to HTTPS when possible.