"When an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node," Unit 42 warns — a concise description of the collapse at the heart of machine identity when a host is compromised.
How SPIFFE/SPIRE issues and verifies workload identities
SPIFFE is an open standard that replaces long‑lived secrets with short‑lived workload identities. SPIRE is a production-ready, open‑source implementation widely deployed in Kubernetes environments. Each workload identity consists of a SPIFFE ID (a URI-style name), an SVID (SPIFFE Verifiable Identity Document, either an X.509 certificate or a JWT), and a trust bundle of trust anchors.
The SPIRE runtime is split between a server (the control plane CA that stores registration entries and issues SVIDs) and an agent that runs on every compute node. The agent accepts local requests over the Workload API (typically a Unix socket such as /run/spire/sockets/agent.sock), performs attestation, caches SVIDs, and handles rotation. Registration entries and selectors live on the server; the agent collects selectors from the runtime and matches them to cached registration entries to decide which SVID a workload may receive.
Cgroup spoofing: how root access turns node trust into identity theft
Unit 42 demonstrates a post‑exploitation technique that requires root on a Kubernetes node. The SPIRE agent uses the requesting process PID to feed workload‑attestor plugins (commonly k8s and Unix). The k8s plugin reads /proc/<pid>/mountinfo or /proc/<pid>/cgroups, extracts the pod UID and container ID (via GetPodUIDAndContainerID), and then queries the kubelet for pod metadata using the agent service account token at /var/run/secrets/kubernetes.io/serviceaccount/token.
Because selector evaluation relies heavily on a process’s cgroup path, an attacker with root can manipulate cgroup metadata. Unit 42 shows that by creating a mock cgroup path (or writing into the original cgroup) and placing the attacker shell’s PID into cgroup.procs, the agent can be tricked into believing the attacker process belongs to a different workload. The agent then issues the target workload’s SVID to the attacker‑controlled process — including the private key in the X.509 SVID case or a signed JWT SVID — allowing impersonation of co‑located workloads and access to services that trust that identity.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleSpooffe: an automated tool for defenders to enumerate exposed identities
To operationalize the technique for defensive testing, the researchers developed Spooffe, an open‑source tool that scans a node for running workloads, discovers their cgroup paths, replicates them as mock cgroups for the tester’s process, and queries the local SPIRE agent to collect resulting SVIDs. Spooffe can enumerate all workload identities present on a compromised host and includes additional capabilities such as agent impersonation checks.
Unit 42 emphasizes that these demonstrations were built to test exposure; they also note that Unit 42 has not observed this technique exploited in the wild.
Mitigations: harden the node and reduce attack surface
- Assume that root access to a node grants access to all cryptographic identities scoped to it. The researchers recommend organizations model threat scenarios accordingly.
- Reduce node‑level exposure: harden nodes, restrict root access, prohibit privileged containers and host access, and minimize reliance on weak selectors that can be spoofed by manipulating cgroup metadata.
- Palo Alto Networks lists defensive controls that can help: Cortex XDR and XSIAM for multi‑layer protection against post‑exploitation activity, and Cortex Cloud Identity Threat Detection to baseline access patterns and detect identity abuse. The company also encourages organizations with urgent concerns to contact the Unit 42 Incident Response team, and provides regional contact numbers.
What this means for technologists, procurement leaders, and incident responders
- Technologists and security teams: Treat node compromise as equivalent to compromise of all identities issued to that node. Test deployments against selector‑spoofing techniques (for example, using Spooffe) and review workloads and registration entries for overbroad selectors.
- Procurement and enterprise security decision‑makers: Prioritize controls that limit host‑level privilege, disallow privileged containers and direct host access, and require vendors to document how their identity solution defends against node‑level compromise.
- Incident responders and defenders: Use defender tools and telemetry layers to detect post‑exploitation behavior; Unit 42 shared these findings with Cyber Threat Alliance members to accelerate mitigations and customer protections.
The core takeaway is stark and specific: SPIFFE/SPIRE cryptography and short‑lived credentials provide strong workload‑to‑workload guarantees only so long as the node itself is trustworthy. Unit 42’s work shows how, once that assumption is broken by root access, an attacker can manipulate cgroup metadata to collapse identity isolation and harvest valid SVIDs. For organizations using SPIFFE/SPIRE, the logical next step is to harden the host boundary and test for the exact selector‑spoofing techniques the researchers have published.
Original report: https://unit42.paloaltonetworks.com/kubernetes-spiffe-spire-identity-spoofing/
