Zero trust for Kubernetes fails without identity-aware access

At a glance

What this is: This is an analysis of why zero trust in Kubernetes depends on identity-aware access rather than network trust, with request-level policy as the key control.

Why it matters: It matters because Kubernetes programmes that still treat internal traffic or static credentials as trusted will miss the access model shift now required across NHI, human, and tool-based access.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Pomerium's guide to achieving zero trust in Kubernetes

Context

Kubernetes zero trust is the practice of treating every request as untrusted until identity and policy prove otherwise. The problem is that many cluster designs still assume an internal network boundary, which no longer exists once developers, workloads, and tools operate across clouds and remote environments.

That assumption is especially brittle when access depends on long-lived credentials or static configurations. Identity-aware access changes the control point from where traffic comes from to who or what is making the request, and under what policy.

For IAM and platform teams, the governance question is not whether Kubernetes can be secured, but whether existing trust models still match how access actually happens.

Key questions

Q: How should security teams implement zero trust in Kubernetes environments?

A: Start by moving authorization to the request edge, where each call is evaluated against identity, context, and policy. Use SSO-backed access for humans, avoid shared tokens, and ensure cluster permissions are tied to named identities. Zero trust in Kubernetes works when trust is removed from network location and rebuilt around per-request verification.

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: What breaks when Kubernetes access still depends on the internal network?

A: What breaks is the assumption that internal traffic is trustworthy. Once developers, workloads, and tools operate across clouds or remote locations, network position stops proving identity or intent. Access decisions based on IP ranges or VPN presence leave dashboards, APIs, and services exposed to any actor that reaches the boundary.

Q: Who should be accountable for Kubernetes access revocation and audit?

A: The IAM or platform security team should own revocation design, while application and cluster owners should validate that policy, impersonation, and logging work together. Accountability matters because access removed in one system must disappear at the cluster boundary too. If revocation is not observable, the programme cannot prove that zero trust is actually enforced.

Technical breakdown

Identity-aware access proxying in Kubernetes

An identity-aware access proxy sits in front of cluster resources and evaluates each request before it reaches the target service. Instead of trusting network position, it checks identity, context, and policy at request time. In Kubernetes this is useful because ingress, dashboards, and APIs often expose different risk profiles but still need a consistent authorization layer. The proxy can pass authenticated identity headers downstream, letting applications and cluster controls make decisions based on the real caller rather than an IP range or VPN session.

Practical implication: place policy enforcement at the request edge so cluster access is evaluated before the workload ever sees it.

SSO-backed kubectl access and service account impersonation

kubectl access becomes safer when the user authenticates through SSO and the access layer impersonates the human to the Kubernetes API using a service account. That pattern keeps the user identity visible while avoiding static client tokens. RBAC then evaluates the request as a named person with explicit permissions rather than as a shared admin credential. This is important because Kubernetes often mixes human administration and workload authentication in the same control plane, which makes identity traceability easy to lose if access is not brokered carefully.

Practical implication: map kubectl access to named identities and review the impersonation path as part of RBAC governance.

Continuous verification and instant revocation

Zero trust in Kubernetes depends on checking every request, not just authenticating once at login. Continuous verification means access decisions can change as identity, device posture, or policy changes. Instant revocation matters because a disabled user or removed entitlement should stop cluster access immediately rather than waiting for a session timeout. This is the operational difference between perimeter security and identity-first access: the boundary becomes the decision, not the network location.

Practical implication: build revocation and audit into the access path so removed identities lose access cluster-wide without delay.

Threat narrative

Attacker objective: The objective is to gain trusted access to internal Kubernetes resources and extend that access beyond the original request boundary.

1. entry: A user or tool reaches Kubernetes through network trust assumptions, such as a VPN, static ingress rule, or shared credential path that was treated as safe because it sat inside the perimeter.
2. escalation: Once inside, long-lived credentials or loosely scoped access can be used to reach dashboards, APIs, or cluster resources beyond the original intent.
3. impact: The attacker or unauthorized actor can move through internal services, abuse kubectl access, and reach sensitive workloads with limited visibility or control.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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

NHI Mgmt Group analysis

Identity-aware access is the control plane Kubernetes actually needs. Kubernetes security fails when teams treat network location as a trust signal, because the platform was never designed around a stable internal perimeter. Request-level identity and policy are the correct enforcement model when users, services, and tools all reach the same cluster from different contexts. The practical conclusion is that access architecture must move from network trust to identity decisioning.

Standing privilege is the wrong default for cluster administration. Kubernetes programmes that leave long-lived credentials in place create a persistent blast radius across users and workloads. In NHI terms, this is the same failure mode seen in service account sprawl: access remains available long after the operational need has passed. The practitioner implication is that privilege scope has to be evaluated at the request boundary, not inferred from environment membership.

Zero trust for Kubernetes depends on governance, not just tooling. The technical stack can enforce policy, but the programme still has to define who may impersonate whom, which identities are allowed to reach the API server, and how revocation is confirmed. That is why this topic maps cleanly to NIST SP 800-207 Zero Trust Architecture and NHI governance together. The practitioner conclusion is that policy, identity, and lifecycle controls must be designed as one operating model.

Identity blast radius is the right concept for Kubernetes access review. When a single identity can reach multiple services, namespaces, or tools, the question is no longer whether the credential exists, but how far it can travel. This is where human IAM, NHI governance, and cluster administration intersect: the same entitlement can behave differently depending on whether it is bound to a person, service account, or automation path. The practitioner conclusion is to review reach, not just ownership.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most access reviews still miss a large part of the machine identity estate.
• That visibility gap is why Ultimate Guide to NHIs , Standards is a useful next step for aligning Kubernetes access with zero trust controls.

What this signals

Identity-aware Kubernetes controls will increasingly become the baseline for platform teams. As clusters spread across clouds and remote operators, network-based trust breaks down faster than most IAM programmes can adapt. Teams that still depend on perimeter logic should expect more pressure to prove who accessed what, from where, and under which policy, especially where workload and human access converge.

Identity blast radius: the next governance problem is not just whether an identity exists, but how many cluster paths it can reach before revocation takes effect. That matters because platform teams often optimise for convenience during provisioning and only discover overreach during incident response. Mature programmes will treat cluster reach as a lifecycle issue, not a one-time setup task.

The practical signal for practitioners is clear: if your access model cannot distinguish a named user, a service account, and a tool-mediated request, your Kubernetes zero trust design is still incomplete. The control objective now is revocation speed, auditability, and least privilege at the request boundary, not just authenticated entry.

For practitioners

• Replace perimeter trust with request-level policy Move cluster access decisions to an identity-aware control point that evaluates every request before it reaches the API server or internal service.
• Broker kubectl through named identities Require SSO-backed kubectl access and impersonation paths that preserve user identity in audit logs instead of shared admin tokens.
• Review service account reach and impersonation rights Map which identities can impersonate Kubernetes service accounts, then remove broad reach that allows access to dashboards, APIs, or privileged namespaces.
• Enforce revocation at the cluster boundary Verify that disabling an identity in the IdP revokes cluster access immediately and that the revocation path is observable in logs and alerts.

Key takeaways

• Kubernetes zero trust fails when teams rely on internal network trust instead of identity-aware request evaluation.
• Long-lived credentials and broad service account reach enlarge cluster blast radius and make revocation harder to prove.
• Practitioners should align SSO, RBAC, impersonation, and revocation so access is enforced at the cluster boundary.

Key terms

• Identity-Aware Access: Identity-aware access is a control pattern that authorizes requests based on who or what is making them, plus context and policy. In Kubernetes, it replaces network location as the trust signal and gives teams a consistent way to evaluate access before a request reaches a service or API.
• Service Account Impersonation: Service account impersonation is a mechanism that lets an access broker authenticate the real user, then present a Kubernetes service account to the API server on that user's behalf. It keeps human identity visible while avoiding shared tokens and preserving RBAC enforcement at the cluster boundary.
• Continuous Verification: Continuous verification means access is not trusted after login alone. Each request, session change, or policy update can trigger a new decision, which is critical in Kubernetes where users, services, and tools may move between environments and roles without warning.
• Identity Blast Radius: Identity blast radius is the total scope an identity can reach before access is removed or expires. In Kubernetes, it describes how far a human account, service account, or automation path can move across namespaces, APIs, and services if privileges are too broad.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pomerium: How to achieve zero trust in Kubernetes with Pomerium. Read the original.