Kubernetes ingress migration shifts access control into policy

At a glance

What this is: This guide shows how to migrate internal Kubernetes services from NGINX Ingress to identity-aware access so routing and authorization are no longer fused together.

Why it matters: IAM, IGA, and platform teams should care because policy-based access changes where authorization is enforced, how access is audited, and how quickly VPN dependencies can be retired for internal tools.

Context

Internal Kubernetes applications often inherit access control from the network path instead of from identity policy. That creates a governance gap because routing, reachability, and authorization are treated as the same control, even though they answer different questions.

Pomerium's migration guide describes moving internal services from NGINX Ingress to identity-aware access without a disruptive rewrite. The core issue is not the proxy change itself, but the shift from IP-based trust and VPN dependency toward explicit policy enforcement at the access layer.

For platform and identity teams, this is a Kubernetes access governance problem as much as an application delivery change. The article is typical of organisations modernising internal app access one service at a time, starting with tools such as Grafana, Argo CD, GitLab, and internal APIs.

Key questions

Q: What should security teams do when internal Kubernetes apps still rely on VPN access?

A: Identify the internal services that most need tighter access control, then move them behind an identity-aware layer that enforces policy and records decisions. VPNs can stay as a transition mechanism, but they should stop being the default trust boundary for administrative or sensitive applications.

Q: How do organisations know if Kubernetes access control is actually working?

A: Look for evidence that service accounts are tightly scoped, cluster roles are reviewed, and network policies limit lateral movement between namespaces. If access remains broad, static, or undocumented, the control is present in name only. Effective governance produces fewer privileged identities, not just a compliant cluster configuration.

Q: Where does NGINX Ingress fall short for internal application access?

A: It falls short when teams expect routing to do authorization work. Ingress can move packets, but it does not by itself make access decisions based on identity claims or business policy, which is why sensitive internal services need a separate control layer.

Q: What is the difference between ingress routing and identity-aware access control?

A: Ingress routing decides where traffic goes, while identity-aware access control decides whether a request should be allowed at all. Routing is about connectivity and path selection. Identity-aware control evaluates the authenticated subject, current policy, and context before the application is exposed.

Technical breakdown

Decoupling Kubernetes routing from authorization

Traditional ingress setups often blur the line between where traffic is routed and whether a user should be allowed to reach a service. In an identity-aware model, routing still sends the request to the right application, but authorization is evaluated separately using identity claims and policy. That separation matters because IP addresses, subnets, and network location are weak proxies for user intent. Once policy sits at the access layer, the control becomes explicit, auditable, and easier to reason about across internal services.

Practical implication: move authorization decisions out of ingress path assumptions and into policy objects that evaluate identity directly.

How identity claims drive policy-based access

Policy-based access depends on the IdP for authentication and on the access layer for authorization. The article's example uses group membership, such as SRE or platform teams, to allow access to Grafana, but the deeper pattern is that identity attributes become the control plane for internal apps. This is a cleaner fit for Kubernetes because the service does not need to know who the user is, only whether the policy engine allows the session. That reduces reliance on static network allowlists and makes access rules easier to change without reworking application code.

Practical implication: define access rules from identity claims and group membership, not from source IPs or shared network trust.

Audit logging, VPN retirement, and blast-radius reduction

The operational payoff of identity-aware access is not only tighter authorization but also better evidence. When logs capture identity, resource, and decision context, teams can answer who accessed what and why, which is essential for internal administrative systems. The migration also lets organisations shrink VPN usage for internal tools, which reduces standing network exposure and limits the reach of compromised credentials. In practice, the value comes from the combined effect of policy enforcement and observability, not from replacing one proxy with another.

Practical implication: verify that every access decision is logged with identity and context before reducing VPN dependency or decommissioning legacy ingress paths.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
• TeamTNT worm 2020: A TeamTNT cryptomining worm spread through exposed Docker APIs and stole AWS credential files from every host it infected, Cado Security found.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy-based access is the right control boundary for internal Kubernetes applications. When teams leave authorization embedded in ingress and network paths, they are treating reachability as a trust decision. That works until internal services contain administrative functions or sensitive data that need identity-aware decisions instead of subnet-based assumptions. The practitioner takeaway is to align access governance with identity, not with where the packet arrived from.

Ingress migration is really a governance refactor, not just a proxy swap. The article's migration pattern shows that teams can move gradually, but the meaningful change is that access control becomes explicit and auditable rather than implicit and distributed. That improves accountability across platform and identity teams because policy now becomes the place where access intent is expressed and reviewed. The practitioner implication is to treat the migration as a control redesign exercise, not an infrastructure refresh.

VPN retirement becomes credible only when policy and logging replace network trust. VPNs often persist because organisations have not built a sufficiently clear alternative for internal app access. Once identity-aware policy governs admission and logs capture the decision context, the case for keeping blanket network tunnels weakens. The implication for practitioners is to sequence VPN reduction after policy coverage and audit quality are proven, not before.

Blast radius is reduced when network paths stop making access decisions. A compromised credential is less useful when the access layer evaluates identity, policy, and service scope rather than simply accepting network proximity. That changes the security model for internal applications because lateral access through trusted networks becomes harder to justify. The practitioner conclusion is that internal app access should be governed as a policy problem with observable decisions, not as an ingress routing shortcut.

From our research library:

• Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.

What this signals

Policy-based access changes the control point for Kubernetes governance. Teams that keep authorization in ingress logic or VPN reachability are still relying on network trust to answer identity questions. The practical shift is to move admission decisions into policy so internal apps can be governed by identity, not location.

Kubernetes ingress migration is often a staged control transition. The safest pattern is to run old and new access paths side by side long enough to prove that identity-aware policy, logging, and service reachability all behave as expected. That gives platform teams a way to modernise access without breaking internal operations.

Identity-aware access becomes most valuable when it replaces ambiguous trust boundaries. Once internal apps are reached only through explicit policy, the team can reason about access reviews, logging, and VPN retirement as connected parts of one governance model instead of separate infrastructure tasks.

For practitioners

• Inventory internal services that still depend on VPNs or basic auth Prioritise services with administrative controls or sensitive data, such as Grafana, Argo CD, GitLab, Prometheus, and internal APIs, because they benefit most from identity-aware access.
• Constrain network reachability to the identity-aware layer Use Kubernetes NetworkPolicies, security groups, and firewall rules to remove public ingress exposure so requests must traverse the access control layer.
• Define access policies from identity claims Authorize access by groups and other identity attributes instead of IP addresses, then keep authentication in the IdP and authorization in policy.
• Validate denial, approval, and audit evidence Test with different roles to confirm that unauthorized users are blocked, authorized users pass cleanly, and logs capture identity, resource, and decision context.
• Retire VPN access only after policy coverage is proven Reduce or eliminate VPN use for internal tools once identity-aware access is consistently enforced and the audit trail is complete enough for operations and review.

Key takeaways

• Internal Kubernetes access becomes easier to govern when routing and authorization are no longer bundled together.
• The migration pattern is incremental, which lets teams modernise internal services without a disruptive rewrite.
• Policy-based access strengthens auditability and can reduce VPN dependency, but only if identity decisions are enforced consistently.

Key terms

• Identity-Aware Access: Identity-aware access is an authorization model that evaluates who or what is making a request, what it is trying to reach, and under what context. It replaces broad, persistent trust with request-level decisions. In agentic environments, it is the control that can contain a deceived agent before it reaches enterprise systems.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• Ingress Migration: The process of moving traffic handling and access control from one ingress pattern to another without rewriting the application. In this context, the important change is not the proxy swap itself, but the move from implicit network trust to explicit identity-based authorization.
• VPN Dependency: A reliance on virtual private network access as the primary way to reach internal applications. This often expands trust too broadly because network presence becomes a proxy for authorization, which is weaker than policy-based access for sensitive internal services.

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 building or maturing an IAM programme, it is worth exploring.