SPIFFE/SPIRE Identity Spoofing: Root on K8s Node Harvests SVIDs

Executive Summary

Root access on a Kubernetes node is enough to impersonate every workload the SPIRE agent running on that node is authorized to attest, according to research published today by Palo Alto Networks Unit 42. The technique abuses the cgroup metadata the SPIRE agent reads during workload attestation: by spoofing those selectors, an attacker-controlled process can convince the agent to issue it a co-located workload's SPIFFE Verifiable Identity Document (SVID).

Unit 42 says it has not observed the technique exploited in the wild. The research is a post-exploitation analysis, not a vulnerability disclosure — no CVE is cited, and the finding rests on the design assumption that the node itself is trusted. The practical implication for defenders running SPIFFE/SPIRE is blunt: any workload identity scoped to a node should be considered compromised the moment an attacker gets root on that node.

Technical Analysis

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for machine identity, and SPIRE is its reference runtime. The model replaces long-lived secrets with short-lived, cryptographically verifiable workload identities, addressing what the community calls the "Secret Zero" problem — bootstrapping the first credential without a static secret.

Each workload gets three components. A SPIFFE ID is a URI-shaped name such as spiffe://<trust-domain>/<path>, where the trust domain acts as the security boundary. An SVID is the short-lived credential that proves the workload is what it claims; it is signed by the SPIRE server's certificate authority and carries the SPIFFE ID. SVIDs come in two formats: X.509 certificates, typically used for mTLS, and signed JWTs, used as bearer tokens for application-level authorization. A trust bundle — root CA certificates or JWKS — lets relying parties verify that an SVID was issued by a trusted authority within the trust domain.

The SPIRE agent runs on each node and performs workload attestation. It inspects local signals — including Linux cgroup membership — to decide which SPIFFE ID a given process is entitled to. Unit 42's finding is that these signals are attacker-controllable once root is obtained. An attacker who can write cgroup metadata can make a process look like a different, co-located workload, and the agent will issue the corresponding SVID.

Unit 42 developed Spooffe, an open-source tool that automates extraction of co-located workload SVIDs by manipulating cgroup metadata. The tool is positioned for defenders: it lets an operator with administrative access test whether their own node configuration permits this impersonation, and measure the resulting identity blast radius.

Two limits on the finding are worth stating. First, it requires root on the node — this is not a remote or unauthenticated attack. Second, it is a design-level consequence of the node-trust assumption common to machine-identity systems, not a bug in a specific SPIRE release. Unit 42's framing is that the trust boundary at the node is the correct place to reason about exposure.

Tactics, Techniques & Procedures

The sequence is straightforward: gain root on a node, manipulate cgroup metadata so an attacker-controlled process matches a target workload's selectors, trigger attestation against the local SPIRE agent, receive the target's SVID, then present that SVID to downstream services that trust the SPIFFE trust domain. From the perspective of any relying party, the attacker's traffic is indistinguishable from the impersonated workload's.

Because SVIDs are short-lived, the harvested credential has a bounded useful life — but the attacker retains root and can re-trigger attestation, so the window is effectively renewable for as long as the node stays compromised. This maps to credential access and alternate-authentication-material abuse rather than to exploitation of a software flaw.

Mitigations & Recommendations

Unit 42's guidance centers on shrinking the population of identities reachable from a single compromised node. Concretely: harden nodes, restrict root access, prohibit privileged containers and host access, and minimize reliance on weak attestation selectors that are easy to spoof. The last point is the one most directly tied to this research — selectors that depend on mutable local state inherit that state's integrity properties.

The broader recommendation is a threat-modeling change. Organizations designing SPIFFE/SPIRE deployments should assume root on a node yields every cryptographic identity scoped to that node, and scope trust domains and workload registrations accordingly. Teams that want to validate their own exposure can run Spooffe against a representative node to see which co-located SVIDs an administrative-level attacker could obtain.