Notifications
Clear all
Topic starter
11/06/2026 10:53 pm
TL;DR: With Ingress NGINX retired in March 2026, Kubernetes operators lose security patches and bugfixes while evaluating replacements that can preserve reverse proxy behaviour without forcing an immediate architecture overhaul, according to Pomerium. The real issue is that ingress migration becomes an identity and policy decision, not just a routing change.
NHIMG editorial — based on content published by Pomerium: Migrating from Ingress NGINX to Pomerium Ingress Controller
Questions worth separating out
Q: How should Kubernetes teams migrate ingress access without creating policy gaps?
A: Teams should migrate routing and access policy together, with explicit owners for each Ingress object and a review process for any permissive rules.
Q: Why does mandatory TLS matter in ingress controller migrations?
A: Mandatory TLS matters because it removes ambiguity from the transport layer and forces certificate lifecycle management into the migration plan.
Q: What breaks when a permissive ingress policy becomes permanent?
A: A permissive ingress policy turns migration convenience into standing access debt.
Practitioner guidance
- Map ingress routes to policy owners Assign explicit ownership for each Ingress object so routing changes and access policy changes are reviewed together.
- Inventory TLS dependencies before migration Catalogue certificate issuers, renewal paths, secret storage locations, and any workloads that still depend on non-standard TLS handling.
- Use permissive policy only as a temporary bridge Track every route configured with allow any: true or equivalent public access settings, then set a review date for replacing those rules with contextual access conditions.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Ingress NGINX to Pomerium manifest changes for real Kubernetes deployments
- Exact policy annotation examples for permissive access, public unauthenticated access, and authenticated-only routes
- cert-manager integration details for automated TLS provisioning and secret handling
- Guidance on running both controllers side-by-side during migration and gradually moving services over
👉 Read Pomerium's migration guide from Ingress NGINX to Pomerium ingress controller →
Ingress NGINX retirement: what it means for Kubernetes access control?
Explore further
12/06/2026 7:17 am
Ingress migration is an identity governance decision, not a routing upgrade. The article frames Pomerium as a practical replacement for Ingress NGINX, but the real governance question is where access policy lives and how explicitly it is expressed. Once ingress becomes the place where policy is required, Kubernetes teams are making an identity boundary decision at the platform edge. Practitioners should treat controller migration as a chance to redraw enforcement lines, not just preserve traffic flow.
A few things that frame the scale:
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to the State of Secrets Sprawl 2025.
- Around 100,000 valid secrets were found in public Docker images, with ENV instructions alone accounting for 65% of all secret leaks in containers, according to the State of Secrets Sprawl 2025.
A question worth separating out:
Q: Who should own ingress policy in a Kubernetes environment?
A: Ingress policy should be co-owned by platform and security teams, with application owners accountable for the access rules attached to their services. If networking owns the proxy but nobody owns the policy, the controller becomes a configuration tool rather than an enforceable security boundary.
👉 Read our full editorial: Ingress NGINX retirement exposes the limits of reverse proxy trust
