Kubernetes zero trust: what identity-aware access changes for teams

TL;DR: Kubernetes environments that rely on network location, long-lived credentials, and static configurations expose identity and access assumptions that zero trust is designed to replace, according to Pomerium. Continuous verification, identity-aware policy, and request-level authorization become the real controls when clusters, users, and tools all move beyond the perimeter.

NHIMG editorial — based on content published by Pomerium: How to achieve zero trust in Kubernetes with Pomerium

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.

Questions worth separating out

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.

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.

Q: What breaks when Kubernetes access still depends on the internal network?

A: What breaks is the assumption that internal traffic is trustworthy.

Practitioner guidance

• 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.

What's in the full article

Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Kubernetes Ingress Controller deployment guidance for identity-aware routing.
• Example policy annotations for securing internal services and restricting access by domain.
• The kubectl impersonation flow that maps browser-based SSO to Kubernetes API access.
• Support patterns for different deployment models, including Gateway API, service mesh, and forward-auth.

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

Kubernetes zero trust: what identity-aware access changes for teams?

Explore further

View Full Forum →  |  NHI Foundation Course →