Kubernetes security best practices still hinge on identity controls

At a glance

What this is: This is a Kubernetes security best-practices article that frames cluster hardening around access control, secrets handling, network restrictions, and continuous monitoring.

Why it matters: For IAM and NHI practitioners, it reinforces that Kubernetes security is fundamentally an identity and privilege problem, not just a platform configuration exercise.

By the numbers:

• Research from Google has shown that MFA can reduce the likelihood of a breach by over 99% in some cases.

👉 Read StrongDM's article on 15 Kubernetes security best practices

Context

Kubernetes security is the discipline of reducing risk across clusters, workloads, and control planes by limiting what can talk to what, what can be modified, and what credentials can be reused. For IAM and NHI governance, the real issue is that service accounts, tokens, keys, and cluster permissions often become standing access paths that outlive the workload that needed them.

This article treats Kubernetes hardening as a stack of controls, but the underlying message is broader: access design, secret hygiene, and auditability must be managed together. That starting point is typical for teams that have grown Kubernetes organically and now need to govern privilege at scale without assuming the platform will self-secure.

StrongDM describes several control layers, but the operational question for practitioners is how those layers change the trust model around workloads and non-human identities. The answer is that Kubernetes becomes manageable only when identity, network, and secret controls are treated as one governance surface.

Key questions

Q: How should security teams govern Kubernetes service accounts as NHIs?

A: Security teams should treat Kubernetes service accounts as first-class NHIs with owners, scopes, and expiry expectations. The practical model is to inventory them, bind them to specific workloads, restrict their RBAC roles, and remove any account that cannot be tied to an active business function. Without ownership and lifecycle controls, service accounts become standing access paths.

Q: What is the difference between RBAC and Zero Trust in Kubernetes?

A: RBAC limits what an identity is allowed to do, while Zero Trust adds the assumption that every request, path, and context must still be verified. In Kubernetes, RBAC narrows privilege, but Zero Trust also requires network segmentation, continuous authentication, and audit evidence. Teams need both because RBAC alone does not stop lateral movement after compromise.

Q: When does secrets management become an NHI governance problem?

A: Secrets management becomes an NHI governance problem when a credential can be used by a service, bot, or workload to obtain persistent access. At that point, the key question is not where the secret is stored but who owns it, when it expires, how it is rotated, and how it is revoked. That is lifecycle governance, not storage hygiene.

Q: Why do Kubernetes environments increase identity blast radius?

A: Kubernetes increases identity blast radius because workloads, nodes, namespaces, and APIs are densely interconnected, so one compromised credential can often reach more resources than expected. If RBAC is broad and network policies are weak, the initial foothold quickly becomes lateral movement. Practitioners should measure the reachable scope of each identity, not just the number of identities present.

Technical breakdown

How RBAC limits NHI blast radius in Kubernetes

Role-Based Access Control in Kubernetes assigns permissions to users, groups, and service accounts through roles and bindings. In practice, RBAC is how teams prevent a workload or operator identity from reaching nodes, namespaces, or APIs it does not need. The risk is not just excessive permissions in the abstract. It is that a compromised service account can become a pivot point into adjacent workloads, especially when roles are broad, inherited, or difficult to review. RBAC is necessary, but it is only effective when paired with regular entitlement review and namespace design that reflects actual operational boundaries.

Practical implication: Review service-account and operator roles by namespace and remove broad bindings before they become permanent escalation paths.

Why secrets management is a non-human identity control

Secrets in Kubernetes are not just data objects. They are authentication material, including API keys, certificates, tokens, and other credentials that grant machine access. Because Kubernetes does not make secret handling secure by default, teams often end up with credentials stored in code, configs, CI/CD systems, or poorly protected cluster objects. That creates a lifecycle problem, not merely a storage problem. If a secret cannot be rotated, revoked, and traced back to an owning workload, it should be treated as unmanaged NHI access. Encryption helps, but governance depends on inventory, rotation, and offboarding.

Practical implication: Track every secret to an owning workload or service account and enforce rotation and revocation as part of the identity lifecycle.

How zero trust changes Kubernetes network trust

Zero Trust Architecture rejects the idea that an internal request is trustworthy by default. In Kubernetes, that matters because pods, namespaces, and nodes can communicate in ways that make lateral movement easy after a compromise. Network policies create an allowlist of permitted pod-to-pod, namespace, and IP-block communication, which reduces the chance that one compromised component can move freely across the cluster. But network policy is not a full Zero Trust model on its own. The practical value comes when traffic controls, identity checks, and audit logging operate together so that communication is explicitly authorized rather than assumed.

Practical implication: Map allowed service-to-service paths and enforce network policies that match those paths instead of relying on flat internal trust.

Threat narrative

Attacker objective: The attacker aims to convert one compromised Kubernetes identity into broader cluster control and reusable access to additional workloads.

1. Entry occurs when an attacker gains access through a stolen secret, over-broad service account, or exposed API key inside the Kubernetes environment.
2. Escalation follows when the compromised identity has permissions to query cluster resources, read additional secrets, or reach adjacent namespaces.
3. Impact occurs when the attacker uses that access to move laterally across workloads and manipulate or exfiltrate sensitive cluster data.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Identity is the primary control plane in Kubernetes security. Kubernetes hardening often gets described as a network or platform problem, but the durable risk is identity sprawl. Service accounts, API keys, tokens, and operator roles decide what a workload can reach, and those permissions frequently outlive the operational need that created them. Teams that treat Kubernetes as a set of infrastructure controls miss the governance problem. The practical conclusion is that Kubernetes security should be run as identity governance with cluster-specific enforcement.

Secrets are NHI assets, not just configuration objects. Once a secret grants machine access, it becomes part of the non-human identity lifecycle and must be inventoried, rotated, and offboarded like any other credential. Storing secrets in pods is safer than embedding them in code, but it is not sufficient if ownership is unclear or revocation is slow. The field needs to stop treating secret storage and secret governance as the same thing. Practitioners should tie every secret to an accountable workload.

Zero Trust in Kubernetes only works when network policy and access policy are aligned. Pod isolation without identity review still leaves standing privilege intact, while identity controls without traffic restrictions still permit lateral movement after compromise. Kubernetes security teams should think in terms of identity blast radius, meaning how far one stolen credential can travel before being stopped. That framing makes the control objective easier to test. The practical implication is that teams should measure how much access a single identity can realistically accumulate.

Continuous auditability is the difference between policy and governance. The article correctly points to logging, monitoring, and reporting as essential, but in NHI terms they are the evidence layer that proves whether least privilege is actually being enforced. Without usable audit trails, organizations cannot tell whether a service account was overused, whether a secret was rotated, or whether a namespace policy was bypassed. That turns every control into an assumption. Practitioners should insist on evidence, not intention.

Kubernetes security programs need an identity blast radius model. A useful named concept here is the identity blast radius, the maximum scope of damage one compromised NHI can reach through cluster permissions, secrets, and network paths. This article points in that direction even when it does not name it directly. Once teams measure blast radius, they can prioritize the identities that matter most instead of trying to harden every control equally. The practical takeaway is to rank Kubernetes NHIs by reachable privilege, not by count.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• That storage pattern makes Kubernetes governance a lifecycle problem, so teams should pair inventory with NHI Lifecycle Management Guide and OWASP Non-Human Identity Top 10 controls.

What this signals

Identity blast radius will become a more useful planning metric for Kubernetes programmes than raw cluster count. Once teams measure how far one service account can travel through namespaces, secrets, and network paths, they can prioritise the controls that actually reduce breach scope.

Kubernetes teams should expect auditors and risk owners to ask for proof of secret ownership, rotation cadence, and offboarding triggers. That pressure aligns naturally with the NHI lifecycle model and with access-review expectations in NIST Cybersecurity Framework 2.0.

The governance signal is clear: access policy, secret policy, and network policy can no longer be managed in separate queues. For readers building a programme, the next step is to connect workload identity inventory with enforcement evidence so that entitlement drift becomes visible before it becomes incident response.

For practitioners

• Map every Kubernetes NHI to an owner and lifecycle state Inventory service accounts, tokens, certificates, and API keys by namespace, workload, and business owner so you can distinguish active access from orphaned access.
• Reduce RBAC permissions to workload-specific minimums Review roles and bindings for each cluster, then remove cluster-wide permissions, inherited admin paths, and stale namespace access that are no longer required.
• Rotate and revoke secrets on a fixed schedule Treat secret rotation as an identity control, not a vault task, and define revocation triggers for build systems, pods, and service accounts that no longer need access.

Key takeaways

• Kubernetes security is an identity governance problem because workloads, service accounts, and secrets can all become standing access paths.
• RBAC, secret rotation, and network policy only reduce risk when they are managed as one control surface with clear ownership.
• The fastest way to shrink Kubernetes attack paths is to measure identity blast radius and remove privileges that do not map to active workload need.

Key terms

• Identity Blast Radius: The maximum scope of damage a single compromised identity can reach before controls stop it. In Kubernetes, this includes what a service account can query, modify, or pivot into through RBAC, secrets, and network paths. It is a practical way to prioritise controls by likely impact.
• Non-Human Identity: A non-human identity is any credentialed machine actor, including a service account, API key, token, certificate, bot, workload, or AI agent. In Kubernetes, these identities often operate continuously and at scale, which makes ownership, rotation, and revocation essential governance tasks, not optional hygiene.
• Secret Lifecycle: The secret lifecycle is the full path of a credential from creation and storage to rotation, revocation, and retirement. For NHI governance, the key question is whether the secret can still be used, who owns it, and whether its access has been removed everywhere it appears.
• Zero Trust Architecture: Zero Trust Architecture is an approach that assumes no request is trusted by default, even inside the environment. In Kubernetes, that means combining identity verification, network segmentation, and audit evidence so that workloads only communicate when access is explicitly allowed.

Deepen your knowledge

Kubernetes identity governance, RBAC tuning, and secrets lifecycle management 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 access under a single governance model, it is worth exploring.

This post draws on content published by StrongDM: 15 Kubernetes Security Best Practices in 2026. Read the original.