Ingress NGINX retirement exposes the limits of reverse proxy trust

At a glance

What this is: This is a migration guide for moving from Ingress NGINX to the Pomerium ingress controller, with the key finding that operators can preserve reverse proxy behaviour while adding mandatory TLS and access policies.

Why it matters: It matters because ingress is part of the identity boundary in Kubernetes, and IAM, PAM, and workload access teams need to understand where policy enforcement shifts when the proxy layer changes.

👉 Read Pomerium's migration guide from Ingress NGINX to Pomerium ingress controller

Context

Ingress controllers are not just traffic routers, they are policy choke points for Kubernetes applications. When Ingress NGINX retires and security updates stop, operators are forced to decide whether to keep a familiar reverse proxy model or move to a controller that makes TLS and access policy explicit.

That choice affects workload identity, application exposure, and the way access decisions are enforced at the edge. In practice, this is less about a product swap and more about whether the ingress layer continues to rely on implicit trust or starts expressing policy as part of the route itself.

Key questions

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. The safest pattern is to validate side-by-side operation first, then replace broad allow settings with route-specific conditions once traffic and certificate behaviour are stable.

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. If certificates are not inventoried, renewed, and stored correctly, the new controller will expose operational gaps that were previously hidden by weaker ingress assumptions.

Q: What breaks when a permissive ingress policy becomes permanent?

A: A permissive ingress policy turns migration convenience into standing access debt. The organisation may believe policy is in place because the controller requires it, but a broad allow rule leaves little practical control over who or what reaches the application. The result is policy visibility without meaningful restriction.

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.

Technical breakdown

Ingress controller migration and policy enforcement

A Kubernetes ingress controller translates Ingress resources into routing rules and decides how requests reach services. In the example here, Pomerium keeps the same reverse proxy pattern as Ingress NGINX, but requires a policy annotation on every route. That policy can be permissive, such as allow any: true, or more restrictive when organisations are ready. The architectural change is subtle but important: access control becomes part of the ingress definition rather than an afterthought layered elsewhere.

Practical implication: treat ingress manifests as access-policy artefacts, not just networking configuration.

TLS requirements and cert-manager integration

Pomerium requires HTTPS for all routes, which shifts certificate handling from optional hardening to a baseline control. The article shows cert-manager as the operational companion for automatically provisioning certificates into the ingress path. That matters because many Kubernetes environments still allow uneven TLS coverage across public and internal applications. When TLS is mandatory at the ingress layer, certificate lifecycle management becomes part of routine platform governance, not a separate security project.

Practical implication: inventory certificate issuance, renewal, and secret storage before migration, because the controller assumes TLS everywhere.

Permissive policy as a transition state

The migration path preserves familiar reverse proxy behaviour by allowing a permissive policy that effectively mirrors traditional ingress handling. That means teams can move services gradually, validate functionality, and defer stronger policy decisions until later. The technical trade-off is that permissive mode still leaves policy expression in place, so the organisation is no longer relying on absence of policy logic, only on a broad allow rule. This makes future tightening easier, but only if teams actually replace the placeholder with contextual policy.

Practical implication: use permissive mode only as a staging step and track every route that still relies on broad allow rules.

NHI Mgmt Group analysis

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.

Mandatory TLS exposes how much application access still depends on implicit trust. Requiring HTTPS for every route removes the option of leaving transport assumptions ambiguous. That aligns with Zero Trust Architecture thinking under ZT-NIST-207 and NIST-CSF, where protection is not optional plumbing but part of the access path. The practical conclusion is that ingress teams need certificate and policy ownership together, because transport security and route access are now coupled.

Permissive policy is a useful bridge, but it can also hide the fact that policy debt still exists. The article shows that a broad allow rule can preserve current behaviour while teams migrate, which is operationally sensible. But once policy is encoded in the ingress layer, the organisation has already accepted that access decisions belong there. The unresolved issue is whether the permissive rule ever gets replaced with context-aware enforcement, because a migration completed in mechanics only is still governance incomplete.

Zero Trust at the ingress layer starts with making access rules visible enough to be managed. This is where Kubernetes ingress, workload access, and application policy converge. The article signals that teams can evolve gradually instead of redesigning everything at once, which lowers adoption friction. The real test is whether platform and IAM teams can share ownership of ingress policy without drifting back into ad hoc network trust.

Ingress controllers are becoming part of the workload identity control plane. As routing logic and access policy move closer together, the controller stops behaving like a simple network component and starts acting as a governance point for application entry. That is especially relevant for teams mapping application access to NIST-CSF and Zero Trust priorities. Practitioners should expect more scrutiny on how ingress, TLS, and authorization are coordinated.

From our research:

• 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.
• For deeper context on credential governance across machine identities, see Ultimate Guide to NHIs and align ingress policy with workload identity controls.

What this signals

Ingress policy is becoming part of workload identity governance. As Kubernetes teams replace legacy ingress paths, they should expect tighter coupling between routing, TLS, and authorization. The practical shift is not only technical. It is organisational, because the team that owns traffic entry increasingly owns the security boundary as well.

Policy debt will show up first as permissive routes that never get tightened. In the migration pattern described here, a broad allow rule is acceptable only if it is tracked as temporary. Teams that leave those settings in place are preserving old behaviour while missing the chance to move toward explicit access enforcement.

For teams modernising platform access, the useful question is whether ingress is still functioning as a neutral traffic layer or whether it has become the control point where application trust is actually decided. That distinction will shape how quickly organisations can move toward Zero Trust Architecture without disrupting service delivery.

For practitioners

• Map ingress routes to policy owners Assign explicit ownership for each Ingress object so routing changes and access policy changes are reviewed together. This prevents the proxy layer from becoming a hidden security control that no team actually governs.
• Inventory TLS dependencies before migration Catalogue certificate issuers, renewal paths, secret storage locations, and any workloads that still depend on non-standard TLS handling. Pomerium assumes HTTPS everywhere, so missing certificate lifecycle data will slow cutover.
• 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. Treat broad allow rules as migration debt, not a destination.
• Validate side-by-side operation during cutover Run both controllers in parallel while you compare routing, TLS termination, and policy behaviour for critical applications. This reduces the chance that a migration breaks access assumptions hidden in legacy ingress definitions.

Key takeaways

• Ingress migration is also a governance migration, because access policy and routing now need to be managed together.
• Mandatory TLS and explicit policy annotations make hidden assumptions visible, which is useful only if teams are prepared to own the resulting operational work.
• A permissive cutover can reduce migration risk, but it becomes a control failure if organisations never replace it with contextual policy.

Key terms

• Ingress Controller: A Kubernetes component that turns Ingress resources into live routing rules for application traffic. In practice, it often becomes the first policy enforcement point in front of services, which means routing, TLS, and access decisions can be governed together rather than separately.
• Permissive Policy: An access rule that allows traffic broadly while still passing through an explicit policy engine. It is useful during migration because it preserves existing behaviour, but it only works as a temporary state if teams later replace it with contextual restrictions.
• Certificate Lifecycle Management: The process of issuing, renewing, storing, and rotating certificates that secure service communication. For ingress platforms, it is a governance discipline as much as a technical one, because route availability and encryption depend on keeping certificates current and correctly bound.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pomerium: Migrating from Ingress NGINX to Pomerium Ingress Controller. Read the original.