Kubernetes security gaps show why access control still fails at scale

At a glance

What this is: This is an independent guide to Kubernetes security that argues the primary risk comes from access misconfiguration, weak secrets handling, and limited visibility rather than Kubernetes architecture alone.

Why it matters: It matters because Kubernetes security now sits inside the same identity governance problem as NHI, workload access, and privileged human administration, so IAM and PAM teams cannot treat it as a separate DevOps issue.

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.

👉 Read StrongDM's guide to Kubernetes security and access control

Context

Kubernetes security is the discipline of protecting clusters, workloads, and the identities that operate them. In practice, the hardest problems are access control, secrets management, and observability, because Kubernetes is highly dynamic and defaults are often too permissive for production use.

The primary governance gap is not a lack of security features. It is the gap between how teams provision access and how Kubernetes actually behaves under load, across namespaces, nodes, service accounts, and CI/CD-driven change. That is why Kubernetes security belongs in the broader conversation about NHI governance, privileged access, and lifecycle control.

For teams looking to standardise that governance layer, the Ultimate Guide to NHIs is a useful reference point for how non-human identity controls map to access, rotation, visibility, and offboarding in practice.

Key questions

Q: How should security teams reduce Kubernetes access risk without slowing deployments?

A: Start by shrinking the number of standing permissions. Use task-scoped roles, short-lived credentials, and auditable access paths so developers and operators can work without shared kubeconfigs or persistent elevation. The goal is to make access specific to a workload, a namespace, and a time-bound task, not a permanent entitlement.

Q: Why do Kubernetes environments create such difficult identity governance problems?

A: Because Kubernetes changes quickly and often across many layers at once. Human administrators, service accounts, secrets, and automated pipelines all interact through the same control plane, which makes broad permissions easy to hide and hard to review. Governance fails when teams treat those identities as infrastructure details instead of access objects.

Q: What breaks when Kubernetes secrets are handled manually?

A: Manual handling usually creates duplication, stale credentials, and unclear ownership. Once secrets are copied into files, CI jobs, or shared configurations, no one can reliably prove where they exist or who can still use them. That turns rotation into a reactive cleanup exercise instead of a controlled lifecycle process.

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.

Technical breakdown

RBAC and API server control in Kubernetes

Kubernetes RBAC decides who can do what through the API server, which is the control plane entry point for almost every meaningful action in a cluster. The technical risk is that a single over-broad role, shared kubeconfig, or weakly protected API endpoint can turn routine administration into cluster-wide exposure. Authentication, authorisation, and TLS all matter, but RBAC policy is the control that defines blast radius. When RBAC is too coarse, teams lose the ability to separate admin, developer, and workload permissions in a way that reflects operational reality.

Practical implication: review cluster roles and service account bindings before adding more tooling or more clusters.

Secrets management and credential exposure in clusters

Kubernetes secrets are often treated as a convenience layer, but they are still credentials, tokens, and keys with direct security impact. If secrets are stored in plaintext, copied into manifests, or exposed through over-permissioned workloads, attackers can move from one pod to broader platform access very quickly. Encryption at rest helps, but the deeper issue is lifecycle control for the secret itself: who created it, where it lives, how it rotates, and whether it is still needed. In Kubernetes environments, secret sprawl is usually a governance problem before it is a cryptographic problem.

Practical implication: centralise secret creation and rotation instead of allowing teams to embed credentials directly in cluster workflows.

Observability, audit logging, and session visibility

Kubernetes environments create a monitoring problem because configuration, access, and workload behaviour all change quickly. Traditional monitoring can show system health, but it often misses identity-level evidence such as who issued a kubectl command, which service account accessed a resource, or whether access was used outside its intended purpose. Audit logs, session recording, and API visibility close that gap by making access review possible after the fact. Without them, teams can detect outages but still fail to reconstruct how privilege was used during a security event.

Practical implication: collect audit trails that link human and non-human access to specific cluster actions.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Secrets sprawl is the dominant failure mode in Kubernetes environments. The guide’s emphasis on plaintext secrets, exposed dashboards, and manual rotation shows that the real issue is not secret storage alone but uncontrolled distribution. That maps directly to the OWASP Non-Human Identity Top 10 because the risk comes from unmanaged credential lifecycle, not from the presence of Kubernetes itself. Practitioners should treat every workload secret as an identity object with an owner, lifecycle, and revocation path.

Over-permissioned RBAC creates identity blast radius in a way many teams still underestimate. Kubernetes makes it easy to grant access at cluster, namespace, workload, or service-account level, but coarse role design quickly turns into broad lateral movement potential. The named concept here is identity blast radius: the distance a single misused credential can travel before controls stop it. The practitioner implication is to design permissions around task scope, not organisational convenience.

Session visibility is the control that turns Kubernetes access from assumption into evidence. The guide’s focus on audit logging and replay points to a simple truth: without immutable access records, teams cannot distinguish legitimate admin activity from abuse. That aligns with Zero Trust thinking in NIST SP 800-207, where verification must continue beyond initial authentication. The practitioner conclusion is that access governance for clusters must be observable at the session level, not just at the provisioning level.

Kubernetes security is now a governance maturity test, not just an engineering checklist. The article shows that teams struggle most where access, secrets, and operational drift intersect. That means platform teams, IAM teams, and security operations need shared ownership of cluster identity policies, especially where service accounts and human administrators intersect. The practitioner conclusion is that Kubernetes risk is usually a sign of broader identity governance fragmentation.

From our research:

• 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.
• That visibility gap is why Ultimate Guide to NHIs remains a practical reference for mapping NHI ownership, rotation, and offboarding before exposure becomes outage.

What this signals

Secret sprawl is no longer a side issue in Kubernetes operations. Teams that manage clusters at scale are effectively managing an NHI estate whether they call it that or not, because service accounts, tokens, and certificates behave like identities with lifecycle risk. The practical shift is toward governed secret ownership, not ad hoc credential handling.

A stronger programme will treat Kubernetes access as part of the same control model used for workload identity, privileged administration, and offboarding. That means aligning cluster permissions with Zero Trust principles and using the OWASP Non-Human Identity Top 10 as a lens for review.

Identity blast radius: in Kubernetes, a single over-permissioned role can reach far beyond the workload that requested it. The implication for practitioners is clear, access reviews must focus on effective privilege and session evidence, not just what was provisioned on paper.

For practitioners

• 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.
• Treat service accounts as governed identities Assign ownership, expiry, and offboarding steps to each service account so credentials do not survive the workload that created them.

Key takeaways

• Kubernetes security failures usually begin with identity and access mistakes, not with the platform itself.
• The evidence in the guide points to a recurring mix of misconfiguration, exposed secrets, and weak observability as the main risk drivers.
• The most effective response is to govern cluster access as NHI lifecycle management, with tight RBAC, central secrets control, and auditable sessions.

Key terms

• Kubernetes RBAC: Role-based access control in Kubernetes is the policy layer that decides who can perform which actions on cluster resources. In practice, it defines the blast radius of an identity, whether that identity is a human administrator or a service account running a workload.
• Service Account: A service account is the identity Kubernetes uses for workloads, controllers, and automation inside the cluster. It is not a person and should be governed as a non-human identity with ownership, least privilege, lifecycle tracking, and revocation when the workload no longer needs it.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials, tokens, and keys across files, pipelines, manifests, and runtime environments. It creates hidden trust relationships that make rotation, ownership, and revocation difficult, which is why it is a governance problem as much as a storage problem.
• Identity Blast Radius: Identity blast radius is the amount of environment an identity can reach if it is misused or compromised. In Kubernetes, it depends on role scope, namespace boundaries, secret exposure, and whether audit logs and session controls can contain the misuse quickly enough.

Deepen your knowledge

Kubernetes access governance and secrets lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring cluster identity under the same governance model as the rest of your NHI estate, it is worth exploring.

This post draws on content published by StrongDM: Kubernetes Security: Guide to Securing Your Clusters. Read the original.