The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE
Learn how root access on a compromised K8s node allows attackers to utilize SPIFFE/SPIRE metadata to spoof and harvest co-located workload identities.
Learn how root access on a compromised K8s node allows attackers to utilize SPIFFE/SPIRE metadata to spoof and harvest co-located workload identities. This research demonstrates post-exploitation techniques that could allow an attacker with root access on a compromised Kubernetes node to misuse an open standard and reference implementation for machine identity known as SPIFFE/SPIRE to impersonate co-located workloads and harvest SPIFFE Verifiable Identity Documents (SVIDs). We show how the trust assumption at the core of every machine-identity system — that the node is trusted — collapses once an attacker obtains root on that node. The Secure Production Identity Framework for Everyone (SPIFFE)/the SPIFFE Runtime Environment (SPIRE) is widely deployed in Kubernetes and cloud-native environments to replace long-lived secrets with short-lived, cryptographically verifiable workload identities.
If an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node. While several implementations exist, we chose SPIRE for this research because it is widely deployed in Kubernetes environments and fully implements the SPIFFE standard. Furthermore, because SPIRE is open source, we can inspect its internals to understand how the specification works in practice. An attacker with root access on the node can manipulate this cgroup path, potentially tricking the agent into believing the attestation claims belong to a different workload and obtain that workload’s identity.
We could generate key pairs and exchange public keys to communicate through Mutual Transport Layer Security (mTLS ) , but this option raises a few key questions: SPIFFE addresses these issues by standardizing how machines are named and how short-lived credentials are issued. This is a short-lived credential that a workload presents to prove its identity. When workload A needs to communicate with workload B over mTLS, it requests a short-lived credential from the local SPIRE agent. The SPIRE agent periodically synchronizes and caches these registration entries from the server, using them locally during workload attestation to determine which identity applies.
SPIFFE is an open standard for machine identity designed to solve the “Secret Zero” problem — the challenge of securely introducing the initial secret required to bootstrap trust — by replacing long-lived secrets with short-lived workload identities. When deployed correctly, SPIFFE enforces strong identity boundaries between workloads. In this post, we lay the groundwork by explaining machine identity and how SPIFFE establishes and verifies trust in cloud-native environments. Note to readers: If you’re already familiar with SPIFFE/SPIRE concepts and architecture, you can jump directly to Workload Attestation and How the Agent Attests the Workload sections.
Workload B verifies the SVID by validating the signature against the trust bundle, checking the certificate’s expiration, and confirming that the SPIFFE ID matches an expected identity.
What changed
In this way, workloads can have an identity and know who to communicate with.
SPIRE is composed of a few simple pieces (as shown in Figure 2 below): With the SPIRE architecture in mind, we can now walk through how workload-to-workload identity verification works end to end.
With the high-level flow in mind, we can now examine how attestation works in practice.
Who is affected
When designing threat models for SPIFFE/SPIRE, organizations should assume that root-level access to a node grants access to all cryptographic identities scoped to it.
However, these guarantees rely on a core assumption shared by all identity systems that the underlying node is trusted.
It is cryptographically signed by the certificate authority (CA) server and always includes the workload's SPIFFE ID.
The agent attests the workload and forwards the attestation data to the SPIFFE server.
Based on predefined registration policies, the server selects the appropriate SPIFFE ID for the workload and issues a short-lived X.509 SVID.
Before the agent attests the workloads, the SPIRE server’s administrator must register the workload selectors in the SPIRE server so it can later compare them to the selectors in the agent.
Why this matters
If an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node.
While several implementations exist, we chose SPIRE for this research because it is widely deployed in Kubernetes environments and fully implements the SPIFFE standard.
Furthermore, because SPIRE is open source, we can inspect its internals to understand how the specification works in practice.
An attacker with root access on the node can manipulate this cgroup path, potentially tricking the agent into believing the attestation claims belong to a different workload and obtain that workload’s identity.
This could allow the attacker to impersonate the victim workload and access any services or resources trusted under that identity.
When we have root access, we can get the identity of any workload on the node.
The technical picture
We could generate key pairs and exchange public keys to communicate through Mutual Transport Layer Security (mTLS ) , but this option raises a few key questions: SPIFFE addresses these issues by standardizing how machines are named and how short-lived credentials are issued.
This is a short-lived credential that a workload presents to prove its identity.
When workload A needs to communicate with workload B over mTLS, it requests a short-lived credential from the local SPIRE agent.
The SPIRE agent periodically synchronizes and caches these registration entries from the server, using them locally during workload attestation to determine which identity applies.
When a workload wants to authenticate, it requests an identity from the agent over the Workload API (Figure 4, step 1).
When a workload requests an SVID (via FetchJWTSVID or FetchX509SVID ), it connects to the agent Workload API, typically via a Unix domain socket (such as /run/spire/sockets/agent.sock ).
To do this, it uses the SPIRE agent’s service account token, stored at /var/run/secrets/kubernetes.io/serviceaccount/token .
As a first step, we created a registration entry for a pod named workload-a in the server and we verified that we could fetch its identity from the pod: We verified that we could not retrieve this identity from the host by requesting a JWT SVID: We copied this path to a mock cgroup path and wrote our shell’s current PID($$) into the mock cgroup’s cgroup.procs file: Notably, writing the PID directly into the original cgroup path would have also worked.
How organizations are responding
SPIFFE is an open standard for machine identity designed to solve the “Secret Zero” problem — the challenge of securely introducing the initial secret required to bootstrap trust — by replacing long-lived secrets with short-lived workload identities.
When deployed correctly, SPIFFE enforces strong identity boundaries between workloads.
In this post, we lay the groundwork by explaining machine identity and how SPIFFE establishes and verifies trust in cloud-native environments.
Note to readers: If you’re already familiar with SPIFFE/SPIRE concepts and architecture, you can jump directly to Workload Attestation and How the Agent Attests the Workload sections.
SPIFFE ID is a canonical name for a workload identity that follows a URI-style format like spiffe:// / (Figure 1).
The middle part ( example[.]com ) in Figure 1 is the trust domain, the issuer of identity that acts as a security boundary.
What defenders should do now
Workload B verifies the SVID by validating the signature against the trust bundle, checking the certificate’s expiration, and confirming that the SPIFFE ID matches an expected identity.
What to watch next
Watch for additional exploitation reporting, newly published indicators, and changes to vendor guidance.