Kubernetes Identity Attack: How Node Compromise Exposes Workload Identities

Unit 42 has demonstrated how a Kubernetes identity attack that leverages root access on a node running SPIRE can allow an attacker to obtain the valid Kubernetes workload identity of another workload on the same node. The attacker does not need to steal a certificate, compromise the issuing authority, or break SPIFFE cryptography. Manipulating the runtime evidence used during workload attestation can trick SPIRE into issuing another workload’s identity to an unauthorized process.

The credential remains valid. The process holding the credential does not. Unit 42 has not observed the technique being exploited in the wild. The research still exposes a material weakness in how organizations measure the impact of node compromise. Root access can compromise every workload identity available through the affected node.

Cryptographic trust cannot correct a false attestation decision

SPIFFE replaces long-lived secrets with short-lived, cryptographically verifiable workload identities. SPIRE determines which identity a process can receive by comparing runtime selectors against registered workload policies. Unit 42 found that an attacker with root access could manipulate the cgroup information used to associate a process with a Kubernetes workload. SPIRE then matched the forged process context to the victim workload and returned its SVID.

The resulting SVID was not counterfeit. A trusted authority issued and signed the credential. The failure occurred before issuance. SPIRE received false evidence about the requesting process and produced a valid credential from the false evidence. The receiving service would see the victim workload’s SPIFFE identity inside a current credential signed by the correct authority. The attacker executing a workload identity attack would pass the same verification checks as the workload being impersonated.

Kubernetes node compromise can cross every workload boundary on the node

Kubernetes may isolate workloads operationally, but a Kubernetes node compromise allows an attacker to exploit how SPIRE authorizes several workload identities through the same node-level trust boundary. Root access collapses that boundary. An attacker who compromises one workload and reaches the underlying node can potentially impersonate another co-located workload. The second workload may hold access to production databases, internal APIs, cloud services, secrets stores, or administrative systems that the original workload could never reach.

The initial compromise therefore does not define the full incident. The identities available through the node define the potential blast radius. Security teams must stop treating a compromised node as a single infrastructure asset. Every identity scoped to the node, every permission granted to those identities, and every reachable resource must enter the containment decision.

Valid authentication can conceal a workload identity impersonation

Most identity monitoring begins after a credential is presented. A relying service validates the SVID, confirms the issuer, checks the signature and expiration, and accepts the SPIFFE ID. None of those checks reveal whether SPIRE issued the credential to the intended process. The authentication event can therefore look legitimate because the credential is legitimate.

Network controls face the same limitation. The attacker can execute a SPIFFE identity attack locally and use approved service-to-service channels. No stolen secret needs to cross the network. No invalid signature identifies the impersonation. Detection must extend beyond credential validity. Attestation determines which process receives the Kubernetes workload identity. Authorization determines which actions the identity can perform. Reachability reveals which critical resources become accessible through direct and inherited access. A trusted issuer cannot answer all three questions.

Workload placement defines the identity blast radius

Co-located workloads share more than compute infrastructure. Under node-based workload attestation, co-location can create a shared identity blast radius. A development utility, monitoring process, or lower-trust application should not share a node with workloads whose identities unlock materially more sensitive resources unless compensating controls reduce the exposure.

Security teams need a node-level record of every workload identity available through SPIRE and every resource authorized to trust those identities. Workloads with access to production databases, secrets stores, or administrative services should not share that trust boundary with lower-trust applications. A scheduling decision can place a monitoring utility beside a workload trusted by a production database. A root compromise in the lower-trust container can then expose the higher-value workload identity.

Containment must extend beyond the compromised node

Unit 42 recommends hardening clusters against a Kubernetes identity attack, limiting root access, blocking privileged containers and unnecessary host access, and replacing registration entries that depend on weak selectors.

After a Kubernetes node compromise, isolating or rebuilding the host is not enough. Responders must revoke the SVIDs available through the node and investigate access made under each affected SPIFFE ID. The first containment priority is any identity trusted by a production database, secrets store, administrative API, or other high-impact resource. A clean authentication log does not reduce the urgency because the attacker’s credential would pass normal verification.

Rebuilding the node removes the attacker’s original position. Revoking the affected identities and closing their access paths limits further movement.

Unosecur exposes the blast radius behind workload identity

Unosecur discovers non-human identities, connects each identity to its permissions and trust relationships, and maps the critical systems and data within reach. Following a Kubernetes node compromise, security teams can use that identity context to determine which workload identities expand the incident beyond the affected host. Access paths reveal where valid credentials could support lateral movement, privilege escalation, or access to sensitive resources.

Security teams can prioritize identities with direct or inherited access to critical systems instead of treating every exposed SVID as an isolated credential. Cryptographic validation confirms who issued the identity. Unosecur shows what an attacker can reach through it.

Expose the Blast Radius Behind Every Workload Identity →

‍