Root on One Kubernetes Node Could Become Every Workload on It
A workload identity is meant to answer a simple question: which service is asking to connect? On a compromised Kubernetes node, the harder question is who gets to supply the answer. Unit 42 researchers have demonstrated that an attacker with root access to one node can make an identity agent issue credentials for other workloads running on that same node.
This is not a report of a new internet-facing Kubernetes exploit. The attacker must already control the node at root level, and Unit 42 says it has not seen this technique used in the wild. Its importance is what root access means after that first compromise. A service that appears separate at the application layer may still trust an identity issued on the basis of host information an attacker can alter.
The identity boundary begins below the workload
SPIFFE is an open standard for giving software workloads short-lived cryptographic identities. SPIRE is one implementation. Instead of storing a long-lived secret in each service, a workload asks a local agent for an identity document, known as an SVID, which it can use to authenticate to other services. The agent must decide which workload is asking before issuing that document.
In the Kubernetes configuration examined by Unit 42, the SPIRE agent relied in part on Linux control-group, or cgroup, information to attest the requesting process. The researchers showed that an attacker with root on the node could manipulate that information to make its own process appear to belong to a neighbouring workload. The agent then returned the other workload’s valid identity document to the attacker-controlled process.
The certificate or token itself was not forged. It was legitimately issued to the wrong requester because the evidence used to identify that requester came from a host the attacker controlled. Unit 42 built a tool, Spooffe, to automate testing this identity boundary and assess which co-located workloads’ credentials could be obtained after a node compromise.
Why a short-lived credential is not enough
Short-lived identities reduce the danger of secrets lying around for months. They do not solve an attacker being able to ask the agent for a fresh identity while it still controls the node. In the researchers’ demonstration, the identity system did exactly what it was designed to do after accepting the host’s claim about the process. The failure is in treating a compromised node as a trustworthy witness.
The likely blast radius is not every workload in a cluster. The technique shown concerns identities available to workloads co-located on the compromised node and depends on the specific attestation configuration. But that can still be serious. A service running beside the compromised process might have access to a database, message broker or internal API that the attacker could then reach while presenting a valid identity.
What defenders should change in their threat model
Unit 42 recommends treating root-level node compromise as a compromise of all cryptographic identities scoped to that node. That means reducing the chance of node-root access through hardening, restricting privileged containers and host access, and avoiding weak selectors that can be imitated. Security teams should also map which sensitive services and identities share a node, then ask whether one compromised workload could gain privileges that its neighbours trust.
For incident response, isolating a compromised container may not be enough if the underlying host was controlled. Investigators should establish whether the node could have obtained other workloads’ SVIDs, revoke or rotate affected trust material where appropriate, and review service access performed under those identities. These steps follow from the demonstrated risk; they are not evidence that a particular deployment has already been attacked.
Machine identity is a powerful replacement for shared, long-lived credentials, but it cannot be stronger than the evidence used to decide who receives it. The uncomfortable consequence of Unit 42’s work is that a valid identity can still tell the wrong story when the node making the claim is no longer trustworthy. BlackTree has separately examined why signed runtime evidence cannot substitute for a trustworthy execution boundary.
Sources
- Unit 42, The Machine With Many Faces, published 10 September 2026, no time provided, for the demonstrated technique, prerequisites and mitigations.
- SPIFFE project overview, for the standard’s identity model and SVID terminology.
