Kubernetes ingress migration shifts access control into policy

At a glance

What this is: This is a migration guide for moving internal Kubernetes applications from NGINX Ingress to Pomerium, with the key finding that access control can be decoupled from routing without a disruptive rewrite.

Why it matters: It matters because IAM, PAM, and platform teams need a practical path to shift internal access from network-based trust to identity-aware policy enforcement across NHI, autonomous, and human access patterns.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent.

👉 Read Pomerium's migration guide for internal Kubernetes applications

Context

Internal Kubernetes access often starts as a network problem, then becomes an identity problem once teams need finer control over who can reach Grafana, Argo CD, GitLab, Prometheus, and internal APIs. The article argues that teams do not need to rewrite applications to make that shift; they need to move enforcement out of ingress and into policy.

For IAM and platform teams, the practical issue is not whether internal tools can be reached, but whether access is explicit, auditable, and easy to remove when VPN reliance becomes a liability. That is the governance change this migration pattern is trying to unlock: identity-aware access for internal services instead of broad network reachability.

Key questions

Q: How should teams migrate internal Kubernetes apps from ingress trust to identity-aware access?

A: Start with a small set of internal services that are not public-facing and depend on VPNs or basic auth. Put an identity-aware control in front of them, keep routing stable, and validate that policy decisions are logged and understandable before widening the rollout. The goal is to replace implicit network trust with explicit authorization.

Q: Why do IP-based rules fail for internal application access?

A: IP addresses describe network location, not authority. In hybrid work and cloud environments, users and workloads move across networks often enough that location becomes a weak proxy for trust. Identity claims from the IdP give teams a better basis for access decisions because they are tied to the authenticated subject and policy context.

Q: What breaks when internal tools still rely on VPNs and basic auth?

A: The control model becomes broad, hard to audit, and difficult to remove when the organization wants finer-grained access. VPNs may still move traffic, but they do not express who should reach which internal service or why. That leaves teams with parallel trust paths and weaker evidence during reviews or incidents.

Q: How do teams know an identity-aware access migration is ready to replace VPN access?

A: The migration is ready when deny tests, allow tests, and audit logs all line up. Practitioners should be able to confirm that unauthorized requests are blocked, authorized requests succeed, and each decision includes identity, resource, and policy context. If any of those pieces are missing, the old path should stay in place.

Technical breakdown

Decoupling routing from access control in Kubernetes

Traditional ingress handles both traffic routing and, implicitly, a large part of access trust. In this migration pattern, routing continues to send requests to internal services, but authorization moves into an identity-aware layer that evaluates who the requester is before the request reaches the workload. That separation matters because ingress rules are usually too coarse for internal tools that hold administrative or sensitive data. Once policy becomes distinct from routing, teams can keep existing service endpoints while changing the decision point from network location to identity claims.

Practical implication: isolate internal services behind an identity-aware proxy before removing legacy ingress trust paths.

Identity claims versus IP-based trust

The article’s core control shift is from IP address checks to identity claims. An IP tells you where a request came from, not whether the requester belongs to the right group or should access the resource at that moment. Identity claims, usually supplied by the IdP, let policy express group membership and other attributes directly. This is the difference between trusting a location and trusting an authenticated subject. For internal Kubernetes applications, that distinction reduces exposure when users move networks, VPN states change, or remote access patterns become more variable.

Practical implication: define authorization around identity claims and group membership, not source IP ranges.

Audit logs and decommissioning VPN access

A useful migration is not complete when access works. It is complete when the team can verify denials, see successful decisions in logs, and retire older access paths that no longer belong in the control plane. Audit logs should capture identity, target resource, and the policy decision so reviewers can reconstruct who accessed what and why. Over time, decommissioning VPN access for internal tools reduces the number of parallel trust systems administrators must maintain, which simplifies both governance and incident response.

Practical implication: validate decision logging before decommissioning VPN access for internal tools.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity-aware access for internal Kubernetes services is a governance shift, not just an ingress replacement. The article is really about moving enforcement from the network edge to a policy decision point that can be audited and changed independently of routing. That matters because internal tools often carry administrative privilege even when they are not public-facing. For NIST Cybersecurity Framework 2.0 alignment, this is a protect-and-govern problem as much as an access-control one, and practitioners should treat the migration as a control redesign rather than a lift-and-shift.

Policy based on identity claims is stronger than network locality for internal applications. IP-based trust collapses quickly in hybrid and remote environments because location is a weak proxy for authority. Group membership, authentication context, and explicit allow rules create a more defensible decision model for Grafana, Argo CD, and similar systems. The practical conclusion is that internal application access should be expressed in terms IAM teams can review, not network conditions they can only infer.

Access blast radius: once access control is centralized in policy, the real win is not convenience but containment. When internal tools are reachable only through the identity layer, the operator can limit exposure for compromised credentials, separate duties more cleanly, and reduce the number of bypass paths that accumulate around VPNs and basic auth. That makes blast-radius reduction an access architecture outcome, not an afterthought. Practitioners should measure whether legacy paths still create alternate routes to the same systems.

Incremental migration is the right operating model for internal service access modernization. The article’s stepwise approach reflects a broader truth: large-scale access control change succeeds when teams run the old and new models side by side, then remove the weaker one after policy validation. That approach is especially relevant where service teams own different internal tools and cannot tolerate a brittle cutover. The implication is that governance teams need a phased adoption plan, not a one-time migration event.

For non-human access, the same policy principles apply even when the subject is not a person. Internal APIs, automation, and service accounts still need explicit authorization, auditable decisions, and removal of broad trust paths. The distinction is operational, not conceptual: the identity may be a workload or bot, but the governance need is the same. Practitioners should evaluate whether their internal access model can support NHI controls before retiring network-only trust.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which shows how often internal trust still leaks beyond intended control points.
• That governance pattern matters because only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.

What this signals

Access policy will keep moving closer to the workload. Teams that still treat internal applications as a VPN problem will find themselves carrying too many parallel trust paths. Identity-aware access becomes the cleaner operating model because it gives IAM and platform teams one place to review, revoke, and audit decisions across users and non-human access alike.

Access blast radius is the right concept for this migration. When internal tools sit behind explicit policy instead of broad ingress, compromised credentials have fewer alternate routes to the same resource. That makes service access easier to reason about during incident response, and it turns authorization design into a practical containment control rather than a theoretical architecture goal.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs, internal access modernization must account for where credentials actually live. A modern Kubernetes access model is only as strong as the identity and secret hygiene feeding it, so teams should align ingress replacement work with secret discovery and service account review.

For practitioners

• Inventory internal services that still depend on network trust List tools such as Grafana, Argo CD, GitLab, Prometheus, and internal APIs that remain reachable through VPNs, basic auth, or broad ingress rules. Prioritize services with sensitive data or administrative controls first, because those are the ones most likely to benefit from identity-aware access.
• Restrict direct network reachability before policy cutover Update Kubernetes NetworkPolicies, security groups, and firewall rules so the service is only reachable through the identity-aware layer. That keeps the control path consistent while you validate policy logic and audit output.
• Write policy in identity terms, not IP terms Use IdP-backed claims such as group membership to define who can access each internal service. Keep the policy readable enough that IAM and platform teams can review it without reverse-engineering routing exceptions.
• Test deny and allow paths with audit evidence Verify that unauthorized users are denied, authorized users can reach the service, and logs record identity, resource, and decision context. If the log cannot explain the decision, the control is not ready for production review.
• Retire VPN access only after replacement controls are proven Reduce or eliminate VPN access for internal tools after the identity-aware path has been exercised in parallel and the team is confident that no hidden dependencies remain. This removes a parallel trust channel and simplifies incident response.

Key takeaways

• This migration pattern shifts internal Kubernetes access from network trust to explicit identity policy, which is a governance change as much as a technical one.
• The practical value comes from auditability, narrower blast radius, and fewer parallel trust paths once VPN and basic auth are retired.
• Teams should treat identity claims, decision logging, and staged cutover as the core controls that determine whether the migration succeeds.

Key terms

• Identity-aware access: An access model that decides whether a request should be allowed based on authenticated identity and policy, not just network location. In Kubernetes environments, it places authorization closer to the service and makes access decisions easier to audit and change without rewriting the application.
• Ingress control plane: The set of routing and access rules that decides how traffic reaches internal services. In practice, it often blends connectivity and trust in ways that are convenient for operators but too coarse for sensitive internal tools, especially when policy needs to be explicit and reviewable.
• Policy decision point: The place where an access request is evaluated against identity claims, rules, and context before the resource is reached. For internal applications, separating this from routing gives teams a clearer boundary for authorization, logging, and future governance changes.

Deepen your knowledge

Kubernetes identity-aware access migration is a topic covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing ingress trust with policy-driven controls for internal services, it is worth exploring.

This post draws on content published by Pomerium: From NGINX to Pomerium: A Practical Migration Guide for Internal Kubernetes Applications. Read the original.