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

Why This Matters for Security Teams

Ingress-based trust works until an internal service becomes reachable from a broader path than the team intended. In Kubernetes, that usually means a service assumed to be “safe because it is inside the cluster” ends up relying on network location, static headers, or shared secrets rather than explicit identity. That model breaks down fast once teams add multi-tenant clusters, service meshes, CI/CD automation, or internal tools exposed through VPNs.

Security teams are migrating toward identity-aware access because it replaces coarse network trust with per-request authorization tied to a workload, user, or session. This is not just an architecture preference. The OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs both point to the same operational problem: once service access depends on secrets, bearer tokens, or flat network reachability, the blast radius becomes hard to contain. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which makes ingress trust especially risky when internal apps are assumed to be low exposure.

In practice, many security teams encounter lateral movement and privilege abuse only after an internal credential or cluster path has already been used to reach systems that were never meant to be broadly accessible.

How It Works in Practice

The migration usually starts by keeping routing stable and changing only the trust decision. Instead of sending traffic directly to an app based on source IP, VPN membership, or an internal load balancer, teams place an identity-aware control in front of the service. That control can be a gateway, reverse proxy, service mesh policy point, or application-level auth layer, but the key is the same: each request must present verifiable identity and be authorized at runtime.

For Kubernetes workloads, this often means binding access to workload identity rather than to pod network location. Mature patterns use mTLS-backed service identity, OIDC claims, or SPIFFE/SPIRE-issued identities to prove what the caller is. Policy then evaluates context such as namespace, service account, request path, device posture, or environment stage. Current guidance suggests using policy-as-code so decisions are readable, logged, and testable before production rollout. For many teams, that means aligning access rules with Top 10 NHI Issues and identity governance expectations from the Ultimate Guide to NHIs — Key Challenges and Risks.

• Start with one internal app that still depends on VPN reachability or basic auth.
• Put the identity-aware layer in front of it without changing the app URL or service name.
• Require authenticated identity, then authorize by service account, user group, or workload claim.
• Log policy decisions in a way operators can explain during incident review.
• Keep the old path temporarily for rollback, but measure and reduce its use.

Using this approach, teams can prove the access model before scaling to more sensitive apps. These controls tend to break down when legacy workloads cannot present a stable identity or when multiple proxies rewrite headers in ways that make authorization decisions ambiguous.

Common Variations and Edge Cases

Tighter identity-aware access often increases operational overhead, requiring organisations to balance stronger assurance against rollout complexity and application compatibility. That tradeoff is real for Kubernetes environments with mixed workloads, because not every app can support modern auth flows on day one.

Common edge cases include apps that rely on shared back-end sessions, batch jobs that have no human user, and internal tools that were built assuming every request came from a trusted subnet. In those cases, the best practice is evolving rather than settled. Some teams front the app with an identity-aware proxy and preserve the legacy backend unchanged. Others shift authorization into the service mesh or use signed workload tokens for machine-to-machine calls. If the app is especially brittle, the safer path is often to protect it at the edge while planning a later refactor, rather than forcing in-app changes too early.

Another important exception is east-west traffic between internal services. Identity-aware access should not stop at the ingress layer if service-to-service calls still trust the cluster by default. A staged migration should therefore include internal call paths, service accounts, and secret handling. The 52 NHI Breaches Analysis is a useful reminder that once secrets or service identities are overprivileged, the issue is no longer just access control at the edge.

For teams with strict compliance or audit needs, the deciding factor is often whether policy decisions are transparent enough to survive review. If the logs cannot show who or what was authorized, why the decision was made, and whether the request was denied or allowed, the migration is incomplete even if the traffic technically works.

Related resources from NHI Mgmt Group

• How do teams know if identity-aware access is actually improving security?
• How should security teams decide between a lightweight gateway and a full identity provider for self-hosted apps?
• Should teams prioritise zero trust design or access cleanup first?
• How should security teams decide whether JIT access is safe for non-human identities?