Kubernetes uses service accounts and node identities because the API server must distinguish what is making each request. Without tight authorization, a validated identity can still perform dangerous actions beyond its job. Strict boundaries reduce accidental changes, prevent overreach by workloads or kubelets, and keep cluster operations aligned to role and namespace scope.
Why Kubernetes needs separate boundaries for service accounts and node identities
Kubernetes treats service accounts and node identities as distinct subjects because they represent different trust levels and different blast radii. A workload identity should not inherit the authority of the node that hosts it, and a node identity should not be able to act like every pod on that node. Tight boundaries keep authentication from becoming blanket authorization.
The practical reason is simple: the API server can verify who is calling, but it still must decide what that caller may do. If those boundaries are loose, a valid identity can still create pods, read secrets, or change resources far outside its intended scope. Kubernetes security therefore depends on separating identity proof from permission scope, especially across namespace and cluster-wide operations.
That separation is also why Kubernetes guidance around least privilege matters so much. Service accounts are often attached to workloads that only need narrow API access, while node identities support kubelet and node-level operations that are inherently broader. When either identity is over-authorised, a routine compromise can turn into namespace escape, secret exposure, or control-plane abuse. The distinction is especially important when service account tokens or node credentials are long-lived and reused across many requests.
For a broader Kubernetes identity and workload-identity view, NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is a useful foundation, and the NHI Lifecycle Management Guide is helpful where token issuance, rotation, and offboarding need to be handled as control-plane hygiene rather than ad hoc operations.
What goes wrong when the boundary is too loose
The main failure mode is privilege convergence. If a workload can use a service account that can also read cluster secrets, create workloads, or patch bindings, the identity has become a shortcut into broader control. If node identities are too permissive, compromise of the kubelet or node agent can expose workloads running on that host and create a stepping stone into other namespaces or workloads.
Namespace scope is important, but it is not sufficient by itself. Some Kubernetes actions are cluster-scoped, some are namespace-scoped, and some are mediated by admission or controller behavior. A service account that only appears harmless in one namespace can still become dangerous if it can create objects that trigger privileged controllers, mount sensitive volumes, or consume node-level capabilities indirectly.
Operationally, the boundary also helps distinguish normal workload activity from suspicious behavior. A pod that suddenly attempts to query secrets, impersonate other identities, or enumerate cluster-wide resources is no longer behaving like a constrained application identity. For teams that want a control-oriented baseline, the OWASP API Security Top 10 is a useful adjacent reference for authorisation failures, and NIST Cybersecurity Framework 2.0 is helpful for framing identity and access control as part of a broader protection and governance program.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Least Privilege and Access Boundaries | Service accounts and node identities need narrow authorization scopes. |
| NHI-02 — Credential and Token Lifecycle | Kubernetes identities rely on tokens and credentials that must be bounded and rotated. | |
| Recommendation — Apply least privilege to service accounts and node identities. Rotate and bound Kubernetes identity credentials on a defined lifecycle. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations Managed | Kubernetes permissions must be restricted to the intended role and namespace. |
| PR.AC-1 — Identities and Credentials Issued, Managed, Verified, Revoked, and Audited | Service accounts and node identities require governance across issuance and revocation. | |
| Recommendation — Enforce role-appropriate authorization boundaries for cluster identities. Manage Kubernetes identities through controlled issuance, audit, and revocation. | ||
| CIS Controls v8 | 6 — Access Control Management | Least-privilege control is central to separating workload and node authority. |
| Recommendation — Restrict Kubernetes access to only the permissions each identity needs. | ||
| NIST Zero Trust (SP 800-207) | SC-1 — Policy Enforcement Point | Kubernetes authorization depends on enforcing access decisions at the API boundary. |
| Recommendation — Enforce Kubernetes policy at the API server and other decision points. | ||
Practitioner Guidance
What to verify: Check whether each service account is limited to the smallest workable namespace or resource set, and whether node identities can perform only node-required functions rather than workload-level actions. If a service account can read secrets, create workloads, or modify bindings without a clear operational need, treat that as an overreach condition.
Decision rule: If the identity can affect objects outside the workload’s own lifecycle, tighten the boundary before expanding functionality. If a node-level identity is required for infrastructure operations, keep it separate from application permissions and assume the node is a high-value trust boundary rather than a generic execution host.
What good looks like: Workloads use service accounts that are narrowly scoped, short-lived where possible, and auditable by namespace or application. Node identities are stable enough for node management, but not so broad that a single compromised node becomes a cluster-wide administrator.
Practitioner takeaway: Kubernetes identity design works when authentication proves the caller and authorization still constrains the caller’s real-world blast radius, because those are not the same control.
Related resources from NHI Mgmt Group
- Why do Active Directory service accounts complicate zero trust programs?
- How should teams govern Kubernetes service accounts as NHI identities?
- How should teams govern authorization for service accounts and other machine identities?
- How should organisations govern Kubernetes service accounts as identities?
