Root on One Kubernetes Node Is Every Identity on It

Unit 42 published research on September 9 that lands a clean hit on how most teams think about machine identity. An attacker with root on a Kubernetes node can manipulate cgroup metadata and walk off with the identities of every workload running on that node. The researchers have not seen it used in the wild. They did ship a tool, Spooffe, so defenders can test for it themselves.

The finding matters because SPIFFE and SPIRE sit underneath a lot of zero trust claims in cloud-native infrastructure. Both are CNCF graduated projects. That is a strong signal of maturity and adoption. It also means a lot of production trust now rests on one assumption about the node beneath the agent.

Root on one node unlocks every identity on it

SPIFFE solves a real problem. Workloads need identity without long-lived secrets. SPIRE is the runtime that issues short-lived SPIFFE Verifiable Identity Documents, or SVIDs, after it attests to who is asking. That attestation step is the whole ballgame.

On Linux, the SPIRE agent usually answers one question. Which container is this process in? It reads the cgroup path from /proc and matches it against registration entries cached from the server. Root on the node can write to that same data.

The attack is almost boring in its simplicity. Read a victim workload’s cgroup path. Create a mock cgroup with the same path. Write your own shell’s PID into it. Ask the agent for an identity over the Workload API. The agent reads the metadata you just wrote, matches the victim, and hands you a valid short-lived credential. Unit 42 used a separate mock cgroup instead of editing the real one, so the victim workload never noticed a thing.

The node was always the trust anchor

This is not a flaw in SPIFFE, and it is not a patch-the-library problem. Every machine identity system trusts the node it runs on. That assumption held when identity was per-host and boring. It gets shakier when one node runs forty tenants and the SVID opens mTLS to services that believed they had a cryptographic guarantee.

The blast radius is the interesting part. An SVID is a token. Steal the right one and you are not merely on the node. You are whatever that workload is allowed to be. Inside the cluster, mTLS stops being a wall. It becomes a door you already have keys to.

Unit 42 maps the technique to token impersonation and to privilege escalation. That framing is correct. The attack converts a host-level foothold into application-level trust, and it does so with the agent’s own logic.

Treat a node breach as an identity breach

There is no clean fix, so the response has to be operational. Assume that root on a node means every identity on that node is burned. Rotate those SVIDs after an incident and treat the workload identities as compromised, not just the host.

Detect the tampering. New cgroups appearing outside the kubelet’s own hierarchy deserve an alert. So does a process hitting the Workload API socket that does not map to a known pod. Run the researchers’ tool against a test cluster, never production, and measure how far an attacker could actually reach.

Then lean on the layers that still hold. Network policies enforce on pod labels and IP addresses, not on the identity presented at the application layer. Segmentation still contains a stolen SVID. Node hardening, scoped service accounts, and short SVID lifetimes each shrink the window.

The takeaway is uncomfortable. Short-lived credentials are not automatically safe credentials. If the agent will vouch for anyone who can fake the paperwork, the paperwork is the perimeter. Right now that perimeter is a node your threat model already assumed was secure.

Related reading. The Container Runtime Wars Are Over. containerd and CRI-O Both Won.. OpenAI’s Own Agents Broke Into Hugging Face. The Goal Was to Cheat a Test.. A Software Supply Chain Audit Wants Proof, Not a Longer SBOM. AI Infrastructure Runs on Four Layers. Most Break Below the Model..