MITIGATION · m-spiffe
SPIFFE / SPIRE workload identity — cryptographic identities for every agent and service
In most deployments, agents authenticate to one another with long-lived bearer tokens or shared secrets. If any one of those credentials is stolen, the attacker has persistent, platform-wide access until someone manually rotates it. SPIFFE replaces that model: each workload is issued a short-lived, cryptographically verifiable identity document, and every connection requires both sides to present one. No long-lived secrets traverse the network, and a compromised credential is worthless within its TTL.
At a glance
TL;DR
- Every workload gets a SPIFFE ID automatically via the SPIRE Agent on the same node; no bearer tokens or shared secrets are distributed.
- SPIRE issues short-lived X.509 SVIDs and rotates them before expiry; the private key never leaves the SPIRE Agent, so there is no credential hand-off path for an attacker to intercept.
- Two workloads prove identity to each other over mTLS by exchanging SVIDs and verifying them against the shared trust bundle, giving mutual authentication without a pre-shared secret.
- Identity scope is per-workload and per-trust-domain; a compromised workload can exercise only the permissions bound to its own SVID, not those of any adjacent workload.
How it behaves
What it is
SPIFFE (Secure Production Identity Framework For Everyone) is an open standard for assigning cryptographic identities to software workloads: agents, services, and jobs, regardless of where they run or who deployed them. The identity is expressed as a SPIFFE ID, a URI of the form spiffe://<trust-domain>/<path> (for example, spiffe://acme.fintech/payments-agent), and it is delivered as a SVID, a SPIFFE Verifiable Identity Document, which is either an X.509 certificate or a JWT signed by the trust domain's root.
SPIRE is the reference implementation. A SPIRE Server acts as the control plane: it attests each node through a node attestor (Kubernetes PSAT, AWS instance identity document, GCP instance identity, TPM, and others), then issues SVIDs to SPIRE Agents running on those nodes. The SPIRE Agent exposes a local Unix socket implementing the SPIFFE Workload API; a workload calls that socket to receive its current SVID and the trust bundle it needs to verify peer SVIDs. SPIRE rotates SVIDs automatically before they expire, so the workload never handles credential rotation logic itself.
Without SPIFFE, agents typically authenticate with long-lived bearer tokens or shared API keys. Those credentials are static: if one is exfiltrated, the attacker holds it until someone discovers and revokes it. The blast radius is bounded only by the permissions attached to the credential. SPIFFE changes the model: every connection is mutually authenticated over mTLS, each side presents an SVID that was issued to a specific, attested workload, and the private key never leaves the SPIRE Agent's memory. A credential stolen in transit is an expired X.509 certificate. A workload that is compromised holds only its own SVID, not those of any other workload.
Detection signals
- SVID issuance failures by workload. A spike in failures for a specific workload points to attestation misconfiguration, a compromised node, or an attacker probing the registration API.
- mTLS handshake failures by workload pair. Sustained failures on a specific pair indicate a trust-bundle mismatch, an expired SVID that is not being rotated, or a rogue workload attempting to connect.
Threats it covers
-
WHY IT HELPS Privilege Compromise relies on a stolen or misconfigured identity persisting long enough to be useful. SPIFFE issues short-lived SVIDs scoped per workload, so a compromised identity expires quickly and cannot be used to reach other workloads in the same deployment.
-
WHY IT HELPS Credential theft attacks depend on long-lived bearer tokens that remain valid after exfiltration. SPIFFE SVIDs rotate automatically on a short TTL; there is no static credential for an attacker to steal and reuse. Mutual authentication via X.509 SVIDs also ensures that even a replayed token cannot establish a connection without the corresponding private key.
-
WHY IT HELPS Tampering and impersonation on inter-agent channels require the attacker to intercept or substitute traffic from a workload they do not control. mTLS via SVIDs binds each connection to a specific, attested workload identity, so an impersonated or replayed connection is rejected at the transport layer before any payload is delivered.
-
WHY IT HELPS Protocol abuse at MCP and A2A endpoints typically requires either an unauthenticated connection or a credential the attacker can forge. SPIFFE mTLS at the endpoint transport layer requires a valid SVID issued by the trusted SPIRE control plane, which an attacker cannot produce without compromising the attestation mechanism.
-
WHY IT HELPS Wallet key compromise is adjacent to SPIFFE coverage. A wallet signing key stored as a workload-specific secret fetched via the SPIFFE Workload API is not accessible to other workloads even on the same host, bounding the blast radius of any single workload compromise.
-
WHY IT HELPS Smart contract impersonation at the off-chain orchestration layer depends on an agent invoking a contract under an identity it does not legitimately hold. When every agent that invokes a contract does so under a SPIFFE-attested identity, the invocation is attributable to a specific, verified workload, making impersonation require a full workload compromise.
-
WHY IT HELPS MCP client impersonation requires the attacker to produce a valid identity credential for the target client. SPIFFE mutual TLS at the MCP transport layer binds each client connection to a short-lived SVID tied to workload attestation. An attacker cannot impersonate a client without producing a valid SVID, which requires compromising the attestation mechanism, not merely stealing a token.
-
WHY IT HELPS Network-exposed MCP servers are reachable by any caller that can route to the endpoint unless the connection requires mutual authentication. SPIFFE mTLS at the MCP server transport layer forces every client to present a valid SVID before the connection is accepted, closing the unauthenticated network-access path that T43 depends on.
Principle coverage
Defence-in-Depth stage: Prevent — and it advances:
- Zero Trust Zero Trust assumes no identity is inherently trusted. SPIFFE enforces that for workloads by requiring every connection to present a short-lived, attested SVID, so a valid agent process grants nothing on its own without a current credential issued by the trusted control plane.
- Agent-as-principal Identity Agent identity requires that every workload be cryptographically distinguishable and that its credentials cannot be reused beyond their intended scope. SPIFFE provides that guarantee through per-workload SPIFFE IDs, short-lived SVIDs, and mutual attestation, eliminating shared secrets and long-lived tokens as the identity root.
Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.
Implementation options
Four verified deployment paths covering the reference implementation, secrets-manager integration, service-mesh identity, and management UI. SPIRE is the starting point for every path; the others layer on top of or alongside it. Open Service Mesh (Microsoft) is deliberately excluded: it was archived by the CNCF and is no longer maintained.
SPIRE The CNCF Graduated reference implementation of the SPIFFE APIs. A SPIRE Server issues SVIDs to SPIRE Agents running on each node; agents expose the SPIFFE Workload API on a local Unix socket. Current release: v1.14.6. For Kubernetes, use the helm-charts-hardened chart.
Why choose it: The only CNCF Graduated SPIFFE implementation; every other option sits on top of or alongside it. The hardened Helm chart covers multi-cluster and HA configurations. Node attestors cover all common runtimes: k8s_psat, aws_iid, gcp_iit, azure_msi, tpm_devid. Production case studies at spiffe.io include Uber, Square, GitHub, ByteDance, and Pinterest.
More details:
HashiCorp Vault Workloads obtain a JWT-SVID from the local SPIRE Agent and present it to Vault as the authentication credential, replacing static Vault tokens or AppRole secrets. SPIRE issues the JWT-SVID; Vault validates it against the SPIFFE trust bundle.
Why choose it: Best when agents already use Vault for secrets retrieval and you want to eliminate separate Vault tokens. The SVID is the only credential the workload holds; there is no separate Vault token to rotate, leak, or distribute. Documented in SPIFFE official docs as a keyless authentication pattern.
More details:
Istio + SPIRE SPIRE replaces Istio's internal CA (istiod) as the identity issuer. Istio detects a Unix Domain Socket implementing the Envoy SDS API and fetches workload identities from SPIRE instead, producing SPIFFE SVIDs consistently across mesh and non-mesh workloads. This is an optional, non-default configuration.
Why choose it: Best when you need consistent SPIFFE identity across workloads inside the Istio mesh and workloads outside it (VMs, bare-metal agents, sidecars without Envoy). Not needed if all agents live inside a single Istio mesh with no cross-cluster or cross-cloud identity requirements.
More details:
Tornjak An open-source web UI and management API layer for one or more SPIRE deployments. Provides a console for managing workload registrations, inspecting SVID state, and auditing identity events across SPIRE servers. Current release: v2.1.0 (June 2025).
Why choose it: Best when operating SPIRE at a scale where CLI-only management becomes a bottleneck: multiple clusters, multiple trust domains, or a team that needs access to identity state without direct kubectl or spire-server CLI access. Tornjak adds no new identity capability; it is a management and observability layer. For single-cluster deployments, the SPIRE CLI is usually sufficient.
More details:
Trade-offs
- SVID issuance and rotation are asynchronous; there is no per-call latency cost once the workload has a valid SVID cached by the SPIRE Agent. mTLS handshake overhead is the same as any TLS session establishment.
- SPIRE Server requires its own HA datastore (SQLite for single-node; PostgreSQL or MySQL for production HA). Running a second stateful control-plane component is the primary operational cost for small teams.
- Introducing SPIFFE requires changes to every workload's networking layer: all outbound connections must present the SVID, and all servers must validate it. In a large existing fleet this is a multi-month migration; for a new ten-agent deployment it is two to four engineer-weeks.
- Trust-domain federation (cross-domain mutual auth between two independently-operated SPIRE deployments) adds configuration overhead beyond single-domain deployments.
When NOT to use
- Do not deploy SPIFFE when your agents run entirely inside a single cloud runtime that already provides workload identity automatically: AWS Lambda with IAM execution roles, GCP Cloud Run with Workload Identity, or Azure Managed Identity. Running SPIRE alongside the cloud-native identity system creates two identity planes with no security gain.
- Not proportionate for deployments of two or three agents on a single host where the same team operates all workloads and no cross-boundary mutual authentication is needed. Operational overhead exceeds the benefit at that scale.
- Skip if your agents are all behind a service mesh that already enforces mTLS with a SPIFFE-compatible identity (Istio plus SPIRE, Linkerd) and you have no off-mesh workloads requiring the same identity primitive.
Limitations
- SPIFFE provides workload identity at the transport layer; it does not control what an authenticated workload is authorised to do. A valid SVID is proof of identity, not authorisation. Pair with a policy engine (m-opa) for action-level access control.
- Node attestation depends on the trustworthiness of the attestation mechanism. A compromised AWS Instance Identity Document, a stolen Kubernetes service-account token, or a misconfigured JoinToken-based attestor can cause SPIRE to issue SVIDs to unauthorised workloads. Pair with host-integrity attestation (TPM, Measured Boot) for highest-assurance deployments.
- JWT-SVIDs, unlike X.509 SVIDs, are bearer tokens and cannot be revoked before their TTL expires. For high-assurance scenarios prefer X.509 SVIDs with mTLS, where certificate revocation (CRL, OCSP) is available.
- The SPIFFE Workload API is a local Unix socket; workloads must run on the same node as a SPIRE Agent. Deployments that mix containerised and legacy bare-metal workloads require per-node agent deployment or a join-token bootstrapping strategy.
Maturity tier reasoning
- Tier 1 (production-canonical): SPIFFE and SPIRE are CNCF Graduated projects (graduated September 2022), the highest CNCF maturity level. Production deployments at scale are public: Uber, Square, GitHub, ByteDance, Pinterest, Arm, IBM, TransferWise.
- The identity primitive (X.509 SVIDs over mTLS) is built on well-understood cryptography: RFC 5280 X.509, short-lived certificate issuance comparable to ACME, standard TLS. No proprietary or research-stage primitives are involved.
- Remaining operational concerns (HA datastore topology, attestor selection for each runtime, trust-bundle distribution) are deployment decisions, not capability gaps in the standard.
Last verified against upstream docs: 2026-05-30.