Kubernetes ingress needs an identity layer for modern access

At a glance

What this is: This is a practitioner analysis of why Kubernetes ingress needs an identity layer, with the key finding that TLS and routing alone do not provide request-level authorization.

Why it matters: It matters because IAM, PAM, NHI, and workload governance all depend on knowing who or what is requesting access, not just whether traffic is encrypted in transit.

👉 Read Pomerium's analysis of why Kubernetes ingress needs an identity layer

Context

Kubernetes ingress is the entry point for routed traffic, but ingress alone does not decide whether a request should be trusted. The primary gap is simple: encrypted transport can confirm confidentiality, yet it cannot confirm identity, role, or current authorization state. In Kubernetes environments, that leaves teams relying on assumptions that no longer hold once access spans distributed staff, contractors, and dynamic workloads.

The identity problem becomes a governance problem when access decisions are still anchored to the network perimeter. Once inside the perimeter, legacy trust models tend to over-grant access and extend the impact of compromised credentials. For teams building zero trust and continuous verification into Kubernetes, the question is not whether traffic is secure in transit, but whether each request is still entitled to proceed.

Key questions

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

A: Treat ingress as a traffic path, not an authorization boundary. Security teams should keep routing at the ingress layer but enforce identity-aware policy before the application receives the request. That approach lets access decisions use verified identity, role, and context instead of assuming that encrypted traffic is automatically trusted.

Q: Why do perimeter-based trust models break down in Kubernetes environments?

A: Perimeter trust breaks down because Kubernetes access is no longer limited to stable internal users on managed networks. Contractors, partners, and dynamic workloads all create valid request paths that can be over-broadened if location is treated as trust. The result is access that is easier to grant than to govern.

Q: How do teams know if continuous authorisation is actually working?

A: Look for immediate access changes when roles change, engagements end, or device compliance fails. If access continues unchanged after those events, the programme is still relying on session-start trust rather than continuous verification. Effective systems re-evaluate policy on each request and produce auditable decision trails.

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.

Technical breakdown

Why ingress routing is not an authorisation control

Ingress controllers are built to route and terminate traffic, not to make identity decisions. TLS protects the payload in transit, but it does not tell the application who initiated the request, whether the subject belongs to the right group, or whether the access context has changed. That is why ingress without an identity layer is functionally blind to entitlement state. In Kubernetes, the difference matters because workload paths are dynamic and the same service may be reached by users, contractors, automation, or other internal systems.

Practical implication: keep ingress for routing, but place request-level identity and policy evaluation in front of application access.

Continuous authorisation at the edge

Continuous authorization means the access decision is not a one-time event. The policy is checked every time a request is made, so role changes, contract endings, or device compliance changes can affect access immediately. This is a better fit for Kubernetes than perimeter trust because the environment changes too quickly for static trust assumptions to remain reliable. Identity-aware access proxies implement this model by shifting the control point to the edge, where the request context is still visible and actionable.

Practical implication: use per-request policy evaluation for sensitive Kubernetes access paths instead of depending on session-start checks alone.

Identity attributes as the policy input for Kubernetes

An identity layer changes what policy evaluates. Instead of trusting IP address or network location, policy can use identity attributes, group membership, role, and context. That is important in Kubernetes because app-specific authentication layers often lead to fragmented controls and inconsistent audit trails. A centralized identity policy layer reduces those integration seams and makes access decisions auditable against a real subject rather than a network origin. The result is a cleaner governance model across internal services and operator workflows.

Practical implication: standardise policy inputs around identity attributes and remove dependence on network location as a trust signal.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

Ingress without identity is a control gap, not a security boundary. Pomerium's argument is that Kubernetes ingress can move encrypted traffic, but it cannot decide whether the request is still authorised. That matters because modern Kubernetes traffic is not confined to stable internal users and static devices. The practitioner conclusion is that routing and trust are different functions, and ingress only covers the first.

Perimeter trust creates access that outlives its justification. Once access is tied to the network boundary, contractors, partners, and dynamic workloads inherit broad permissions that are hard to tighten later. This is the same governance failure pattern seen whenever identity is inferred from location rather than verified at request time. The practitioner conclusion is that access scope must be evaluated where the request occurs, not where the packet entered.

Continuous authorisation is the operational form of zero trust for Kubernetes. Static session trust assumes that access remains valid long after the business condition changed. In Kubernetes environments, that assumption breaks quickly when roles shift or devices fall out of compliance. The practitioner conclusion is that zero trust only becomes real when each request is re-evaluated against current identity and policy state.

Identity-aware access becomes the missing control plane for workload governance. Kubernetes already has strong routing primitives, but governance requires a second layer that understands subject, role, and context. That is where identity-aware access proxies reduce app-specific auth sprawl and improve auditability. The practitioner conclusion is that workload access governance should be designed around identity first, not bolted onto the network edge.

Continuous verification now applies to human, partner, and workload access alike. The same false assumption appears across IAM, PAM, and NHI programmes: that one authenticated entry point is enough to justify ongoing access. Kubernetes makes that assumption brittle because subjects and paths are constantly changing. The practitioner conclusion is to align request-time authorization across all subject types, not just human users.

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.
• Only 5.7% of organisations have full visibility into their service accounts, which means most Kubernetes-adjacent access governance starts from partial inventory.
• For the lifecycle angle, see Ultimate Guide to NHIs for the governance model that makes continuous verification operational.

What this signals

Identity edge control: Kubernetes teams should expect more policy enforcement to move from the network perimeter to request-time identity checks as zero trust matures. The practical shift is not just technical. It forces IAM, platform, and workload owners to share an access model that can explain who or what is allowed to act, not only where the traffic originated.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the same trust shortcuts that weaken NHI governance also weaken Kubernetes access control. Continuous verification only works when the identity behind the request is trustworthy and its credentials are not floating around unmanaged.

Programmes that already standardise on NIST Cybersecurity Framework 2.0 can map this topic cleanly to Protect, Detect, and Respond. The forward signal is that Kubernetes governance will increasingly be judged by whether access is re-authorised in context, not by whether encryption or perimeter controls are in place.

For practitioners

• Move authorisation to request time Evaluate each Kubernetes request against current identity, role, and policy state rather than assuming that edge authentication is sufficient for the whole session.
• Separate routing from trust decisions Keep ingress focused on transport and routing, then enforce access control in an identity-aware layer that can inspect subject context before the service receives the request.
• Remove network location as a trust signal Replace IP allowlists and perimeter assumptions with policy inputs based on verified identity attributes, group membership, and operational context.
• Centralise audit trails around real subjects Log access decisions against the authenticated user, contractor, or workload identity so reviewers can trace who accessed what and under which policy conditions.

Key takeaways

• Kubernetes ingress solves traffic delivery, but it does not solve request authorisation or current trust state.
• Perimeter-based access models become too broad in Kubernetes because distributed users, contractors, and workloads change the trust problem.
• Identity-aware access at request time is the control shift that turns zero trust from a slogan into an operating model.

Key terms

• Identity Layer: An identity layer is a control layer that evaluates who or what is making a request before access is granted. In Kubernetes, it sits alongside routing and makes authorization depend on verified identity, policy, and context rather than network location alone.
• Continuous Authorisation: Continuous authorisation is the practice of re-checking access every time a request is made instead of trusting a one-time login or session start. For Kubernetes, it closes the gap between authentication and ongoing entitlement when roles, devices, or engagements change.
• Ingress Controller: An ingress controller is a Kubernetes component that routes external traffic to services and often handles TLS termination. It is not, by itself, a full identity control because it can move encrypted traffic without deciding whether the subject should be allowed to proceed.
• Perimeter Trust: Perimeter trust is the legacy assumption that access becomes safe after a request crosses a network boundary. In modern Kubernetes environments, this model over-grants access because identity and authorization change more often than the perimeter can express.

Deepen your knowledge

Kubernetes ingress identity layer and continuous authorisation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning workload access with zero trust in a similar environment, it is worth exploring.

This post draws on content published by Pomerium: Why Kubernetes ingress needs an identity layer. Read the original.