Notifications
Clear all
Topic starter
11/06/2026 10:51 pm
TL;DR: Kubernetes management tools improve cluster operations, but they also expose a persistent access-control gap: shared CLI workflows, API-driven automation, and multi-cluster administration expand the identity surface faster than teams harden it, according to Pomerium. The practical issue is not tooling choice alone, but whether access to Kubernetes resources is governed with identity-aware controls, contextual policy, and lifecycle discipline.
NHIMG editorial — based on content published by Pomerium: 20 Best Kubernetes Management Tools for 2025
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern Kubernetes admin access in multi-cluster environments?
A: Security teams should govern Kubernetes admin access as privileged access, not general operations.
Q: Why do Kubernetes management tools increase identity risk for IAM teams?
A: They concentrate high-impact cluster functions behind interfaces that are easy to reuse, script, or share.
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
- Separate admin, read-only, and automation access Define distinct Kubernetes roles for human operators, monitoring tools, and deployment automation.
- Front cluster access with identity-aware policy Place an identity-aware proxy in front of administrative entry points so access is decided on user identity, device posture, and policy instead of network location alone.
- Audit secrets in code and pipeline tooling Search for credentials in repositories, deployment manifests, CI/CD jobs, and operational notes.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- Side-by-side descriptions of each Kubernetes management tool and its day-to-day use case
- Practical comparisons of monitoring, GitOps, and access-control tooling in cluster operations
- Implementation context for identity-aware access inside Kubernetes workflows
- Additional product-specific notes on where Pomerium fits in a zero trust access model
👉 Read Pomerium's roundup of 20 Kubernetes management tools for 2025 →
Kubernetes management tools: what IAM and zero trust teams need?
Explore further
12/06/2026 7:15 am
Kubernetes management is an identity governance problem, not only an operations problem. The article's tool list is really a catalogue of privileged access surfaces: CLI, dashboards, monitoring, GitOps, and observability all sit close to sensitive cluster functions. Once those paths are normalised, the governance burden shifts from network perimeter control to identity, session, and entitlement control. Practitioners should therefore treat cluster management as a governed access domain, not a utility layer.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- Another 97% of NHIs carry excessive privileges, which means Kubernetes admin paths often sit inside a broader entitlement problem rather than an isolated tooling issue.
A question worth separating out:
Q: How do organisations reduce standing privilege in Kubernetes operations?
A: They reduce standing privilege by limiting persistent cluster-admin rights, separating break-glass access from daily operations, and tying each credential or role to an owner and an expiry condition. Access should be time-bounded, reviewable, and revoked when the operational need ends.
👉 Read our full editorial: Kubernetes management tools expose the identity gap in cluster access
