HashiCorp Vault Brings Workload Identity with SPIFFE Under One Roof
Machine identity is getting harder to manage, not easier. As infrastructure sprawls across clouds, containers, and services, teams need more than a way to name workloads, they need a reliable path from identity to access. HashiCorp has published a detailed guide showing exactly how HashiCorp Vault works as a SPIFFE identity issuer and broker, filling the gap that most workload identity discussions leave open.
The problem, as HashiCorp explains, is that most teams focus on proving who a workload is. The harder question is what happens next. A workload can present a valid identity and still have no consistent route to the secret, certificate, or database credential it needs. That gap is where HashiCorp Vault workload identity with SPIFFE becomes essential.
SPIFFE, Secure Production Identity Framework For Everyone, provides a portable, platform-agnostic way to represent machine identity. It uses a structured SPIFFE ID in a uniform URI format, such as spiffe://trust-domain/workload-path, to uniquely identify any workload regardless of where it runs. The framework delivers a cryptographic identity document called an SVID, a trust bundle for verification, and a local Workload API for automatic rotation. Crucially, though, SPIFFE defines the identity standard, not the access control layer.
That is precisely where SPIRE and Vault each play their role. SPIRE handles deep runtime attestation, verifying workloads at the node and process level before issuing an identity. However, it comes with infrastructure overhead: agents, servers, plugins, and lifecycle management. Not every team is ready for that investment as a first step. Many need a consistent authorization control plane sooner.
Vault steps in here. Through its SPIFFE auth method and SPIFFE secrets engine, Vault validates incoming SPIFFE identities, mints JWT-SVIDs, issues PKI certificates with SPIFFE URI SANs, and publishes OIDC discovery endpoints so downstream services can verify tokens independently. It also supports acting as an upstream certificate authority for SPIRE when deeper attestation is required.
HashiCorp illustrates this with four practical scenarios under a demo called HashiBank. First, Kubernetes microservices authenticate to Vault and receive short-lived X.509 certificates for mutual TLS, each embedding a distinct SPIFFE ID. Second, a workload receives a JWT-SVID from Vault’s SPIFFE secrets engine, which a downstream API then validates using Vault’s public OIDC discovery document, no callback to a central provider needed per request. Third, a workload already using SPIRE fetches a JWT-SVID from its local SPIRE agent and presents it to Vault, which translates that identity into dynamic PostgreSQL credentials. Fourth, SPIRE itself is configured to use Vault’s PKI engine as its upstream certificate authority, giving enterprises a hardened trust anchor.
Together, these patterns draw a clear line: SPIFFE solves the identity language problem. Vault solves the authorization and credential brokering problem. SPIRE remains the right choice when strict runtime attestation is non-negotiable. The three work in layers, not in competition.
For teams ready to act, HashiCorp recommends starting with Vault as the workload identity control plane. The full Vault + SPIFFE demo repository is available on GitHub, with runnable Enterprise lab scenarios covering all four architectural patterns. Teams can also review the SPIFFE secrets engine docs and SPIFFE auth method docs to configure dynamic identity issuance for their own environments.
