Notifications
Clear all
Topic starter
08/06/2026 5:07 pm
TL;DR: Kubernetes adoption is rising faster than security maturity, and the result is a familiar pattern: misconfigurations, exposed dashboards, over-permissioned roles, and weak observability, according to StrongDM and cited survey data from CNCF and Red Hat. The governance problem is not Kubernetes itself but the access model around it, where static credentials and unmanaged RBAC still dominate.
NHIMG editorial — based on content published by StrongDM: Kubernetes Security: Guide to Securing Your Clusters
By the numbers:
- According to the CNCF 2023 Annual Survey, more organizations than ever are running Kubernetes in production.
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
Questions worth separating out
Q: How should security teams reduce Kubernetes access risk without slowing deployments?
A: Start by shrinking the number of standing permissions.
Q: Why do Kubernetes environments create such difficult identity governance problems?
A: Because Kubernetes changes quickly and often across many layers at once.
Q: What breaks when Kubernetes secrets are handled manually?
A: Manual handling usually creates duplication, stale credentials, and unclear ownership.
Practitioner guidance
- Map every cluster role to a business task Replace broad admin-style bindings with namespace- and workload-specific permissions so each role reflects a real operational duty, not a convenience shortcut.
- Eliminate plaintext secret handling in manifests and pipelines Move credentials into a central secrets manager and require rotation for keys, tokens, and certificates that are currently copied into Kubernetes configs.
- Turn on API audit trails and session replay Record kubectl activity, API calls, and privileged sessions so you can reconstruct who accessed which resource and when.
What's in the full article
StrongDM's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Kubernetes hardening guidance for API server, kubelet, and etcd access control
- Specific examples of RBAC, network policy, and secrets handling patterns in live cluster environments
- Session visibility, audit logging, and SIEM integration detail for Kubernetes admin activity
- Practical setup guidance for using centralized access controls across namespaces and clusters
👉 Read StrongDM's guide to Kubernetes security and access control →
Kubernetes security gaps: what IAM teams need to fix now?
Explore further
08/06/2026 7:07 pm
Kubernetes security exposes the same identity failure modes that govern every NHI programme. The article repeatedly returns to the same pattern: static credentials, over-permissioned roles, weak logging, and secrets stored where they should not be. That is not a Kubernetes-only problem, it is a non-human identity problem expressed through cluster tooling. The practitioner conclusion is that cluster security and NHI governance should be managed as one control surface, not two separate ones.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- In the same survey, 45% of organisations said lack of credential rotation is the top cause of NHI-related attacks, which is why lifecycle control matters more than one-time hardening.
A question worth separating out:
Q: Who should own Kubernetes access governance in an enterprise?
A: Ownership should be shared, but accountability should be explicit. Platform teams manage the cluster mechanics, IAM teams govern identity policy, and security teams verify auditability and risk. Without named ownership for roles, secrets, and service accounts, reviews become periodic paperwork instead of active control.
👉 Read our full editorial: Kubernetes security gaps show why access control still fails at scale
