Zero trust for Kubernetes fails without identity-aware access

At a glance

What this is: This is a Pomerium analysis of why zero trust in Kubernetes breaks down without identity-aware access, continuous verification, and request-level authorization.

Why it matters: It matters because Kubernetes teams have to govern access decisions around users, services, and kubectl sessions as identity events, not just network events.

Context

Kubernetes zero trust is the problem space here: once clusters, developers, and internal services move across clouds and remote work patterns, the old assumption that internal network traffic is safe stops holding. Identity-aware access changes the control point from where a request comes from to who or what is making it and whether that request should be allowed now.

The article argues that Kubernetes environments often still depend on long-lived credentials and static configurations, which leaves trust decisions outside the access request itself. For IAM and platform teams, that means the governance question is not only whether a user authenticated, but whether each action is separately authorised at cluster entry and at the API boundary.

Key questions

Q: What breaks when Kubernetes access is controlled only by network location?

A: Network-only control breaks because it does not verify who is acting, what role they hold, or whether the access is still appropriate. In Kubernetes, that can allow a trusted network path to expose cluster-admin functions, secrets, and workloads. Identity-aware policy is needed to replace location as the trust signal.

Q: Why do long-lived Kubernetes credentials increase security risk?

A: Long-lived credentials extend the window in which stolen or over-scoped access can be reused across cluster resources. They also weaken accountability because the same credential can be shared, copied, or reused outside its intended context. In Kubernetes, short-lived, identity-bound access reduces the chance that an old entitlement becomes a standing foothold.

Q: How can security teams know whether kubectl access is actually governed?

A: Kubectl access is governed when every operator action is tied to a real identity, a logged policy decision, and a revocable access path. If administrators can still rely on static tokens, shared credentials, or unmanaged bypass routes, the control is not truly identity-aware. Auditability and revocation are the clearest signals.

Q: When should organisations treat Kubernetes administration as privileged access?

A: Organisations should treat Kubernetes administration as privileged access whenever a user can change cluster state, expose services, or reach the control plane. Those actions can alter workloads, permissions, and data paths at high speed. Applying privileged access controls to kubectl and related tooling reduces hidden standing authority.

Technical breakdown

Why Kubernetes zero trust needs per-request identity checks

Kubernetes was built around trusted internal traffic and operator-managed access patterns, so it does not natively treat every request as a fresh trust decision. Zero trust changes that by requiring continuous verification of the user, workload, or tool making the request. In practice, this means access policy must be evaluated at request time rather than inferred from network location, session origin, or prior login state. For platforms that expose dashboards, APIs, and kubectl access, the control point shifts from the perimeter to the action itself.

Practical implication: enforce authorization at request time instead of relying on cluster adjacency or authenticated session state.

How identity-aware proxies change kubectl and API access

An identity-aware proxy sits between the caller and the Kubernetes control plane or service endpoint, authenticates the request, and applies policy before forwarding it. For kubectl, the model can impersonate the real user to the API server so Kubernetes RBAC still evaluates the request against the correct identity. That keeps access decisions tied to the actual operator rather than to a shared token or static network rule. The architectural value is not the proxy itself, but the fact that identity becomes part of the authorization path.

Practical implication: map human and operator access through identity-backed entry points before it reaches the Kubernetes API.

Why long-lived credentials and static configs undermine zero trust

Long-lived credentials and static configurations create standing trust that survives long after the original context has changed. In Kubernetes, that can mean a compromised laptop, a breached pod, or an outdated token still has enough authority to move through the cluster. Zero trust is trying to replace durable trust with short-lived, contextual authorization, but those older patterns keep reintroducing persistence into the access layer. The issue is not just credential theft. It is that persistent credentials keep the trust model from being re-evaluated at the moment of use.

Practical implication: reduce standing trust by removing credentials and policy paths that remain valid across unrelated tasks.

Threat narrative

Attacker objective: The attacker wants durable cluster access that can be reused without repeated authentication or authorization checks.

1. Entry occurs when a developer laptop or pod is compromised and the attacker inherits access assumptions tied to that device or workload context.
2. Escalation follows when long-lived credentials or static configurations let the attacker move beyond the original request boundary without a fresh identity check.
3. Impact is reached when the compromised access path reaches cluster services or the Kubernetes API with enough authority to act as a legitimate operator.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity-aware access is the control Kubernetes zero trust actually depends on. Network boundaries do not describe who is making a request, and that is the original failure mode in Kubernetes environments. When developers work remotely, services span clouds, and tooling like kubectl reaches directly into the control plane, identity has to replace network location as the basis for trust. Practitioners should treat every request as a governed decision point, not a trusted continuation of a prior session.

Standing access is the conceptual mismatch Kubernetes zero trust exposes. Long-lived credentials and static configurations were designed for environments where access changed slowly enough to be assumed stable. That assumption fails when cluster access must be evaluated per request and per action. The implication is that zero trust programmes for Kubernetes are not just access modernisation projects; they are a challenge to the idea that durable privilege is acceptable inside a dynamic platform.

Request-level authorization is the named control pattern that matters here. The article’s substance points to a practical governance shift: access should be verified at the moment a user, service, or tool asks to do something, not when the environment was first trusted. That aligns with OWASP-NHI thinking on standing privilege and with Zero Trust Architecture principles that assume breach and verify continuously. Practitioners should make request-level authorization the default design assumption for Kubernetes.

kubectl access is now an identity governance surface, not a developer convenience. Once command-line access is tied to the IdP and evaluated through identity-aware policy, operator access becomes auditable, revocable, and context-aware. That matters because Kubernetes administration often escapes the same scrutiny applied to human IAM, even though it can carry equivalent blast radius. Teams should govern administrative tooling with the same rigor they apply to privileged human access.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust Identity Guide

What this signals

Identity-aware access is becoming the practical boundary for Kubernetes governance. The old split between human IAM and platform administration is too narrow for clusters where developers, services, and tools all exercise authority through the same control plane. Teams should expect zero trust programmes to move closer to request-level authorization and away from perimeter-era assumptions.

Standing privilege is the quiet design flaw in many Kubernetes access models. Once a token, config, or route remains valid beyond the task that justified it, the control plane becomes easier to misuse and harder to audit. That is why identity-bound entry points and short-lived access paths matter more than simple network segmentation.

Zero trust in Kubernetes is less about adding a proxy than about changing the decision model. If the programme still trusts internal traffic, it has not really shifted to continuous verification. The operational test is simple: can you explain, revoke, and audit every privileged request as an identity event?

For practitioners

• Define request-level authorization for cluster access Move Kubernetes access decisions into the request path so each dashboard, API, or kubectl action is evaluated against identity and context before it reaches the cluster.
• Replace standing kubectl trust with IdP-backed access Tie kubectl usage to your identity provider so operator access can be authenticated, impersonated, and revoked through the same governance model used for human identity.
• Remove long-lived tokens from operator workflows Eliminate static credentials where possible and use short-lived, identity-bound access for cluster administration and service exposure.
• Log who accessed what and when Keep per-request audit records that capture the identity, target, and outcome of each access decision so teams can investigate and recertify cluster access paths.

Key takeaways

• Kubernetes zero trust fails when access still assumes internal traffic is trustworthy.
• Standing credentials and static configurations keep trust durable in a system that needs fresh decisions.
• Identity-aware access makes request-level authorization, auditability, and revocation the real control points.

Key terms

• Identity-Aware Access: Identity-aware access is an authorization model that evaluates who or what is making a request, what it is trying to reach, and under what context. It replaces broad, persistent trust with request-level decisions. In agentic environments, it is the control that can contain a deceived agent before it reaches enterprise systems.
• Request-level Authorization: Request-level authorization means access is decided for each request rather than once at login or network entry. It lets operators scope permissions by route, method, and identity, which is far more precise than broad network access and better suited to distributed systems and NHIs.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Authentication proxy: An authentication proxy sits in front of a service, verifies identity and policy, and only then forwards requests to the backend. For remote MCP servers, it creates the control layer that the underlying tool server usually lacks on its own.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.