Kubernetes internal apps: what changes when access becomes policy-based?

TL;DR: Moving internal Kubernetes applications from NGINX Ingress to identity-aware access does not require a rewrite, according to Pomerium, but it does change where teams enforce authorization, how they log decisions, and how quickly they can retire VPN access. The security model becomes cleaner only when routing, identity, and policy are deliberately separated.

NHIMG editorial — based on content published by Pomerium: From NGINX to Pomerium: A Practical Migration Guide for Internal Kubernetes Applications

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.

Questions worth separating out

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.

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

A: IP addresses describe network location, not authority.

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.

Practitioner guidance

• 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.
• 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.
• Write policy in identity terms, not IP terms Use IdP-backed claims such as group membership to define who can access each internal service.

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 Kubernetes network restriction guidance for forcing traffic through the identity-aware layer
• Example route and policy configuration for internal services such as Grafana and Argo CD
• Practical validation checks for allow, deny, and audit-log behaviour during migration
• A staged decommissioning approach for replacing VPN access without disrupting internal tooling

👉 Read Pomerium's migration guide for internal Kubernetes applications →

Kubernetes internal apps: what changes when access becomes policy-based?

Explore further

View Full Forum →  |  NHI Foundation Course →