How should security teams govern Kubernetes service accounts as NHIs?

Why This Matters for Security Teams

Kubernetes service account are not just cluster plumbing; they are workload identities that can authenticate, authorize, and persist long after the workload that created them has changed. That makes them classic NHIs: machine-held identities that need ownership, scope, and lifecycle controls. If teams leave them untracked, they quietly become standing access paths into namespaces, secrets, and cloud resources. The governance gap is especially dangerous because service accounts are often created automatically, reused across deployments, and granted broad RBAC roles by default.

NHI governance guidance from NHI Management Group shows that only 5.7% of organisations have full visibility into their service accounts, while 71% of NHIs are not rotated within recommended time frames, leaving access in place far longer than intended, as discussed in Ultimate Guide to NHIs and Top 10 NHI Issues. That risk is amplified when teams rely on static role assignments instead of reviewing actual workload behaviour.

Current guidance from NIST Cybersecurity Framework 2.0 supports ownership, least privilege, and continuous monitoring as practical controls, but Kubernetes only delivers those outcomes when service accounts are treated as governed identities rather than defaults. In practice, many security teams discover over-broad service account access only after a compromised pod, misconfigured namespace, or abandoned deployment has already exposed it.

How It Works in Practice

The operational model starts with inventory. Every service account should be mapped to a specific workload, namespace, owner, and business purpose. If the account cannot be tied to an active function, it should be removed or disabled. Next, restrict the RBAC role to the smallest set of verbs, resources, and namespaces the workload actually needs. That means separating read and write paths, avoiding cluster-admin equivalents, and reviewing bindings whenever a deployment changes.

From there, security teams should align identity, secrets, and runtime controls. A service account token should be short-lived where possible, with automount disabled for workloads that do not need it. Secrets should not be embedded in images, config files, or CI/CD variables when a vault or external secret manager can issue and rotate them. The NHI lifecycle controls described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs are a useful reference point here, especially for registration, rotation, and offboarding.

Practitioners should also monitor service account usage for drift: unusual namespaces, new API calls, failed auth bursts, and workloads using accounts they were not assigned. That monitoring should be paired with periodic access recertification and an explicit offboarding step when the workload is retired. NIST’s Cybersecurity Framework 2.0 reinforces this operational loop: identify, protect, detect, respond, and recover. These controls tend to break down in multi-tenant clusters with shared namespaces and inherited cloud IAM because ownership becomes ambiguous and RBAC sprawl grows faster than reviews can keep up.

• Assign every service account a named owner and a documented workload.
• Use least-privilege RBAC and avoid shared accounts across applications.
• Disable long-lived token patterns where a shorter-lived workload identity is available.
• Review service account bindings whenever pods, namespaces, or CI/CD pipelines change.
• Revoke accounts immediately when the workload is decommissioned or replaced.

Common Variations and Edge Cases

Tighter service account governance often increases deployment friction, so organisations must balance release speed against identity risk. That tradeoff is real in platforms that rely on shared cluster services, legacy controllers, or external integrations that were never designed for per-workload identity.

Best practice is evolving for these edge cases. Some environments still need exceptions for platform operators, admission controllers, or backup tools that require broader access, but those exceptions should be time-bound, logged, and reviewed. Where possible, use JIT elevation for administrative tasks instead of permanent privilege. For highly automated pipelines, there is no universal standard for this yet, but the direction of travel is clear: short-lived credentials, explicit approval gates, and policy checks at request time are safer than standing RBAC grants.

In regulated or high-assurance environments, service account governance should also be linked to audit evidence. That includes proof of ownership, token rotation, offboarding records, and monitoring coverage. The research in 52 NHI Breaches Analysis shows how quickly machine identities become breach paths when they are left unmanaged, while NIST Cybersecurity Framework 2.0 provides a defensible structure for documenting those controls. Shared service accounts, long-lived tokens, and namespace-wide default permissions remain the hardest cases because there is no reliable way to prove which workload used the access after the fact.

Related resources from NHI Mgmt Group

• How should security teams govern Active Directory service accounts?
• How should security teams govern non-human identities alongside human accounts?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?