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

NHI Mgmt Group · 2026-06-11T00:12:20+00:00

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. Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “From NGINX to Pomerium: A Practical Migration Guide for Internal Kubernetes Applications”. 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. 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. Q: Where does NGINX Ingress fall short for internal application access? A: It falls short when teams expect routing to do authorization work. Practitioner guidance 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. Bottom line: Internal Kubernetes access becomes easier to govern when routing and authorization are no longer bundled together. Explore furtherView Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →

Topic starter 12/06/2026 6:02 am

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.

A few things that frame the scale:

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

A question worth separating out:

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.

👉 Read our full editorial: Kubernetes ingress migration shifts access control into policy

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

Deepen Your Knowledge

Subscribe to the NHI & AI Identity Journal

Subscribe to the NHI & AI Identity Journal