How should security teams control Kubernetes access when ingress is already in place?

Why This Matters for Security Teams

Kubernetes ingress is useful for routing, TLS termination, and exposing services, but it does not answer the real security question: who or what is allowed to call the workload once traffic arrives. When teams assume ingress equals trust, they often leave service accounts, API paths, and internal workloads overexposed behind a clean-looking edge. That gap is especially dangerous for non-human identities and automated service-to-service access, where abuse can move faster than manual review.

NHIMG research shows the scale of the identity problem behind modern infrastructure: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges in the broader environment. That is why ingress should be treated as a traffic path, not a policy boundary. Security decisions belong closer to the application, where identity, request context, and intended action can be verified together. This aligns with the direction of the OWASP Non-Human Identity Top 10 and the governance themes in the Ultimate Guide to NHIs.

In practice, many security teams encounter lateral movement and privilege abuse only after a workload has already accepted traffic that ingress was never meant to authorize.

How It Works in Practice

The practical model is layered: ingress handles routing and edge protections, while identity-aware enforcement happens before the request is processed by the app or service. That usually means combining Kubernetes-native controls with workload identity, policy evaluation, and short-lived credentials. A common pattern is to let ingress accept the connection, then require the caller to present a verifiable identity token or mTLS-backed workload identity at the service layer.

For Kubernetes environments, that identity should be tied to the workload rather than the network location. Current guidance suggests using workload identity primitives such as SPIFFE/SPIRE or OIDC-backed service identities so the cluster can prove what the caller is, not just where the call came from. Policy engines can then evaluate request context at runtime. Frameworks such as OPA or Cedar are often used to enforce rules like service identity, namespace, requested operation, and whether the action is allowed in that moment. This is closer to intent-based authorization than static RBAC.

• Keep ingress for routing, TLS, and basic edge filtering.
• Require authenticated service-to-service identity inside the cluster.
• Use short-lived tokens or certificates with automatic revocation.
• Evaluate policy at request time, not only at deployment time.
• Log identity, request path, and decision outcome for later review.

This matters because ingress-only designs tend to flatten all internal traffic into a trusted zone, which is exactly what attackers exploit after a single pod, token, or service account is compromised. That is why NHIMG’s Key Challenges and Risks guidance stresses visibility, rotation, and privilege control alongside boundary design. These controls tend to break down in large, multi-tenant clusters with shared namespaces and legacy services because identity propagation and policy enforcement become inconsistent across mixed workloads.

Common Variations and Edge Cases

Tighter request-level authorization often increases operational overhead, so organisations have to balance stronger control against rollout complexity and latency. That tradeoff is real in clusters with older applications, opaque service meshes, or teams that still depend on static kubeconfig credentials. Current guidance suggests phasing in controls by namespace, service tier, or risk level rather than attempting a big-bang replacement of ingress trust assumptions.

There is no universal standard for every Kubernetes deployment yet, especially when east-west traffic crosses multiple clusters, cloud accounts, or platforms. In those cases, teams may need to combine ingress policy, network policy, workload identity, and external policy-as-code enforcement. The important point is consistency: the request should be evaluated using who the caller is, what it is trying to do, and whether the context matches approved behaviour. That approach is also consistent with the zero-trust direction described in the Ultimate Guide to NHIs — Standards.

Edge cases often show up when traffic is proxied through API gateways, service meshes, or shared ingress controllers that obscure the original identity. In those environments, security teams should verify that identity is preserved end to end and that authorization is not reduced to network origin alone.

Related resources from NHI Mgmt Group

• How should teams migrate internal Kubernetes apps from ingress trust to identity-aware access?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams handle access requests when ITSM tools are already in place?
• How should security teams choose between vaulting and just-in-time access?