Topic starter
24/06/2026 9:16 pm
TL;DR: Kubernetes zero trust fails when access still leans on network location, long-lived credentials, and static configurations, according to Pomerium. Kubernetes access governance shifts to request-level authorization, auditability, and revocation when identity becomes the trust signal.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “How To Achieve Zero Trust In Kubernetes With Pomerium”.
Key questions
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.
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.
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.
Glossary terms: Identity-Aware Access, Request-level Authorization, Standing Privilege, Authentication proxy
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 21 hours ago by NHI Mgmt Group
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