SPIFFE/SPIRE: When Node Compromise Breaks Workload Identity
Palo Alto Unit 42 shows how root access to a Kubernetes node can undermine SPIFFE/SPIRE workload identity and expose co-located service credentials.
Workload identity systems are intended to reduce reliance on long-lived secrets. In Kubernetes environments, SPIFFE and its reference implementation, SPIRE, can issue short-lived, cryptographically verifiable identities to services and use them to authorize mutual TLS or application requests. That model is powerful, but it depends on an assumption that is easy to overlook: the node hosting the workload and the identity agent must remain trustworthy.
Research from Palo Alto Unit 42 examines what happens when that assumption fails. The organization demonstrated that an attacker with root-level access to a compromised Kubernetes node could manipulate the metadata used during workload attestation. In the researchers’ test environment, this enabled an attacker-controlled process to obtain identities associated with other workloads running on the same node.
Unit 42 states that it has not observed this technique being exploited in the wild. The work is therefore best understood as a post-compromise risk assessment: it does not describe an initial intrusion into a cluster, but it does show how a node-level breach can expand into an identity-level breach.
The central security boundary
SPIFFE provides a standard way to name workloads and issue credentials that prove those names. A workload receives a SPIFFE ID, such as a URI identifying a trust domain and workload path. It may then receive an X.509 SVID for certificate-based authentication or a JWT SVID for application-level authorization. A trust bundle allows other workloads to verify that the credential was issued by an accepted authority.
SPIRE implements these functions through a server, agents and workload-attestation mechanisms. The SPIRE server acts as a certificate authority and stores registration entries that associate workload identities with selectors. An agent runs on each compute node, accepts local requests through the Workload API, gathers workload attributes, communicates with the server and returns credentials when the attributes satisfy a registration policy.
In Kubernetes, those attributes can include the namespace, service account, pod identity, container information and other metadata. The agent also uses operating-system information collected through the /proc filesystem and related runtime structures. The result is an identity decision based on a combination of Kubernetes and host-level observations.
This design creates a clear trust boundary. SPIFFE and SPIRE can strongly authenticate a workload only if the agent can reliably determine which workload is making the request. Once an attacker controls the node as root, the operating-system evidence used for that determination is no longer inherently reliable.
How the demonstrated attack works
Unit 42’s demonstration focused on Linux control-group, or cgroup, information. The SPIRE Kubernetes workload-attestor plugin uses process information to associate a requesting process with a container and pod. It can inspect cgroup-related paths to identify the container and pod, then query Kubernetes metadata to collect selectors for that workload.
The researchers found that root access allowed them to manipulate the cgroup context associated with their own process. By presenting metadata corresponding to another workload, the process could cause the local SPIRE agent to evaluate selectors as though the request originated from that workload.
In the test case, a direct identity request from the host did not receive the target workload’s identity. After the researchers changed the process’s cgroup context to resemble the target workload, the same general request returned a JWT SVID associated with that workload. The credential contained the target SPIFFE identity, demonstrating that the agent had accepted the spoofed attestation data.
This is not a weakness in the cryptographic signature on the SVID. The credential was issued by the trusted SPIRE authority and could be validated by services that trusted the relevant trust domain. The problem occurred earlier, when the agent decided which workload was entitled to receive the credential.
Put differently, the attacker did not need to forge a certificate or break the signing algorithm. The attacker caused the identity system to issue a legitimate credential for the wrong process.
Why co-location matters
The demonstrated impact is tied to workloads sharing a node with the compromised process. Unit 42’s conclusion is that root access on a node should be treated as access to the cryptographic identities scoped to that node. The attacker may be able to request identities belonging to multiple co-located workloads, depending on their registration policies and the information available to the local agent.
That creates several possible consequences. A stolen SVID could allow a malicious process to authenticate to services that trust the corresponding SPIFFE ID. It could also enable access to resources governed by application-level authorization based on a JWT SVID. The exact impact depends on what the impersonated workload is permitted to access and how relying services validate identity, audience and authorization.
The research does not establish that every deployment exposes the same set of identities or grants the same access. Selector design, agent configuration, workload placement and downstream authorization all influence the resulting area of impact. However, the core post-compromise condition is broadly important: identity isolation between workloads cannot be assumed after the host enforcing attestation has been taken over.
Spooffe and the defensive value of testing
To automate its research, Unit 42 developed Spooffe, an open-source tool that can scan a node for running workloads, identify their cgroup paths and test whether those paths can be replicated for the tool’s own process. The research describes the tool as a way for defenders to assess whether an attacker with administrative access could retrieve identities from co-located workloads.
The tool is significant less because it introduces a new form of credential theft than because it turns an architectural assumption into a testable condition. Security teams can use an authorized assessment process to determine whether a node compromise would expose identities beyond the initially compromised workload. Testing should be carefully scoped, performed in a controlled environment and coordinated with platform owners, because identity retrieval can affect real authorization boundaries.
What organizations should do now
1. Treat root on a node as an identity incident
Incident-response playbooks should not classify a compromised Kubernetes node solely as a host intrusion. If SPIRE is deployed there, assume that identities available through the local agent may have been exposed or misused. Review the workloads on the node, their SPIFFE IDs, their registration entries and the services that trust them.
2. Harden nodes and restrict privileged access
Unit 42 recommends hardening nodes, restricting root access and prohibiting privileged containers and unnecessary host access. These controls reduce the likelihood that a workload-level compromise can cross into the node’s operating-system boundary. Cluster policies should be reviewed for settings that allow containers to access host namespaces, host filesystems or other node-level interfaces without a clear operational requirement.
3. Review identity placement and blast radius
Map which workloads share nodes and identify identities that can access sensitive services. Where practical, avoid concentrating high-value workloads or broadly trusted identities on the same nodes. Node segregation is not a substitute for host security, but it can reduce the number of identities exposed by a single node compromise.
4. Use precise registration policies
The research specifically advises minimizing reliance on weak or easily spoofable selectors. Teams should review registration entries that authorize identities using broad namespace, service-account or similarly coarse conditions. Narrower policy can limit unintended identity overlap, although it does not restore trust in a node that an attacker already controls.
5. Protect the SPIRE agent and its interfaces
Review permissions around the Workload API socket, the agent process, its service account and the host paths used for attestation. Access should be limited to the processes that genuinely require workload identity. Kubernetes permissions granted to the agent should also be documented and periodically reassessed against the minimum required for the deployment.
6. Monitor for identity misuse
Detection should combine host, Kubernetes and identity telemetry. Investigate unexpected root activity, changes to cgroup structures, unusual access to the SPIRE agent socket, identity requests from processes that do not match expected workload behavior and authentication using a workload identity from an unexpected location or process context.
Teams should also baseline normal use of SVIDs, including requesting workload, destination service, audience and timing. A short-lived credential limits exposure duration, but it does not prevent misuse during its validity period. If compromise is suspected, assess whether affected identities should be revoked or rotated through the organization’s SPIRE operating procedures and whether relying services require additional containment.
What remains unknown
The supplied research does not identify a real-world victim, threat actor, campaign, malware family, CVE or malicious infrastructure. It also does not claim that the technique has been observed in active attacks. The demonstrated behavior depends on root-level access to a Kubernetes node, so the research should not be interpreted as evidence that an external attacker can obtain SPIFFE identities without first compromising the relevant host boundary.
The precise impact in a production environment will vary with node permissions, workload placement, selector strength, SPIRE configuration and the authorization decisions made by downstream services. Organizations should validate those factors in their own environments rather than assuming that the demonstration maps identically to every deployment.
Conclusion
SPIFFE/SPIRE can replace durable application secrets with short-lived, verifiable workload credentials, but it cannot by itself preserve workload identity boundaries after the node performing attestation has been compromised. Palo Alto Unit 42’s research shows that root access can let an attacker manipulate cgroup-based evidence, obtain co-located workload identities and potentially use legitimate credentials under another workload’s name.
The practical lesson is architectural: node integrity is part of the identity system’s security model. Kubernetes hardening, strict privilege controls, precise registration policies, careful workload placement and identity-aware monitoring should therefore be treated as complementary controls. A compromised node should trigger an investigation into every workload identity that the node could have issued or exposed.