Topic starter
24/06/2026 9:16 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “How To Achieve Zero Trust In Kubernetes With Pomerium”.
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.
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: 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.
Practitioner guidance
- 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.
Bottom line: Kubernetes zero trust fails when access still assumes internal traffic is trustworthy.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 6:24 am
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.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Zero trust for Kubernetes fails without identity-aware access