SPIFFE/SPIRE Implementation Guide: Replacing Long-Lived Cloud Credentials with Workload Identity
Proactive Security for the AI Era
NodeZero continuously and autonomously pentests infrastructure, identity, cloud, and now web applications, chaining weaknesses across every domain the way real attackers do. Every finding ships with replayable proof showing exploitable business impact, not theoretical risk.
Long-lived static credentials, API keys checked into a CI variable, service account JSON keys downloaded once and never rotated, shared secrets copy-pasted between teams, share one structural weakness: they are valid until someone manually revokes them, and nothing in the system enforces an expiration on that trust. A leaked key from a log line, a compromised build artifact, or a departing contractor's laptop stays usable indefinitely unless a human catches it and rotates it. This guide is about closing that gap for service-to-service and service-to-cloud authentication using SPIFFE and SPIRE, the open standard and reference implementation for cryptographic workload identity. It is worth being explicit about scope, because Decryption Digest has already published two related guides that cover a narrower, adjacent problem: our earlier posts on workload identity federation for CI/CD pipelines cover OIDC token exchange specifically for build runners authenticating to a cloud provider (see the CI/CD OIDC guide and the GCP-specific GitHub Actions walkthrough below). Those guides solve 'my pipeline needs to call AWS or GCP without a stored key.' SPIFFE/SPIRE solves a broader problem: every workload in your environment, a pod in a Kubernetes cluster, a VM in a data center, a container on bare metal, needs a verifiable runtime identity it can present to other workloads, to a service mesh, to a secrets manager, or to a cloud IAM provider, regardless of whether that workload ever touches a CI/CD pipeline. SPIRE issues short-lived SVIDs continuously to running workloads, not just to a build job at pipeline execution time, and it federates outward into systems like HashiCorp Vault and Microsoft Entra ID rather than being tied to a single cloud provider's OIDC trust relationship. If your problem is exclusively 'GitHub Actions needs to assume an AWS role,' our CI/CD OIDC workload identity federation guide and its GCP-specific GitHub Actions walkthrough are the faster path. If your problem is 'our microservices, our mesh, and our on-prem workloads all still share static secrets with each other and with the cloud,' this is the guide for that.
Prerequisites
Before starting a SPIRE deployment, confirm the following exist or are planned. SPIRE is infrastructure you operate continuously, not a script you run once, so skipping any of these turns the rollout into a series of production incidents rather than a controlled migration.
A defined trust domain
SPIFFE identities are namespaced under a single trust domain string (for example spiffe://yourcompany.internal) that every SPIRE server and agent in the deployment must agree on. Pick this once, deliberately, before any registration entries exist; changing it later means re-registering every workload.
Kubernetes, a service mesh, or a defined bare-infrastructure inventory
SPIRE's node attestation plugins are built around specific platforms: Kubernetes (via the projected service account token attestor, k8s_psat), AWS EC2, Azure MSI, and GCP IIT are all officially supported. If your workloads run on bare metal or unsupported infrastructure, you need a join-token or custom attestation plan before deployment, not after.
An existing secrets manager or cloud IAM you intend to federate into
SPIRE issues identities; it does not replace Vault's secret storage or a cloud provider's IAM policy engine. Know in advance whether the first federation target is HashiCorp Vault (for internal secret retrieval), Azure AD/Entra ID or another cloud IAM (for cloud resource access), or both, since the registration and audience configuration differs for each.
A rollout plan that does not require a big-bang cutover
SVIDs and static credentials can coexist during migration. Plan to onboard one service or namespace at a time, validate SVID-based auth end to end, and only then decommission the static credential for that service, rather than cutting every workload over simultaneously.
Implementation procedure
The following steps deploy SPIRE server and agents, register workloads, issue SVIDs, and federate into Vault and Entra ID. This procedure assumes a Kubernetes-based deployment, the best-documented and most common starting point, but the same sequence (server, agent, node attestation, workload registration, federation) applies to non-Kubernetes environments with different attestor plugins.
1. Deploy the SPIRE server
Install the SPIRE server as a StatefulSet in a dedicated namespace, configured with your chosen trust domain and a persistent datastore for its registration entries and CA keys. The server is the source of truth for which SPIFFE IDs exist and what selectors identify them; treat its storage and its signing key with the same operational rigor as a certificate authority, because that is functionally what it is.
2. Deploy SPIRE agents and perform node attestation
Deploy the SPIRE agent as a DaemonSet so one instance runs on every node. On startup, each agent performs node attestation, presenting evidence (a Kubernetes projected service account token via the k8s_psat attestor, or a cloud provider's instance identity document on AWS/Azure/GCP) to prove the node's identity to the server. A successful attestation issues the agent its own SPIFFE ID, which becomes the parent identity for every workload it will later attest on that node. Register the agent's own node identity on the server explicitly as part of this step; an agent with no matching registration entry cannot attest anything running on it.
3. Register workloads with selectors
For every workload that needs an identity, create a registration entry on the SPIRE server keyed to a SPIFFE ID and a set of selectors (in Kubernetes, typically namespace and service account) that the agent uses to recognize the workload at runtime. During workload attestation, the agent inspects a running process or pod, compares its attributes against the selectors in cached registration entries, and issues the matching SVID only if a registration exists. No registration entry means no identity, by design; there is no default-allow path.
4. Issue and consume SVIDs via the Workload API
Workloads fetch their SVIDs (X.509-SVIDs for mTLS between services, or JWT-SVIDs for presenting to an external verifier like Vault or a cloud IAM) from the local SPIRE agent over the SPIFFE Workload API, typically a Unix domain socket. SVIDs are short-lived by default and the Workload API handles automatic rotation; the workload's application code should call the Workload API client library rather than reading a certificate file from disk, since there is no long-lived file to read.
5. Federate with HashiCorp Vault for secret retrieval
Configure Vault's SPIFFE auth method to trust your SPIRE deployment's trust bundle. A workload fetches a JWT-SVID or X.509-SVID from its local agent and presents it to Vault's auth/spiffe endpoint; Vault validates the SVID against the trusted bundle and issues a short-lived Vault token scoped to a policy, which the workload then uses to read the secrets it actually needs. Vault does not issue SPIFFE identities itself in this pattern, it only validates identities that SPIRE already issued, so the trust flows one direction: SPIRE is the identity authority, Vault is a relying party.
6. Federate with Azure AD/Entra ID for cloud resource access
Deploy the SPIRE OIDC discovery provider alongside your server so it publishes a standard OpenID Connect discovery document and JWKS endpoint over HTTPS on a domain you control. In the JWKS signing key configuration, enable the use parameter (set_key_use) because Entra ID expects it, and configure the server's CA to issue RS256-signed JWT-SVIDs since Entra ID does not accept SPIRE's default ES256 signing for this flow. In Entra ID, add a federated identity credential to the target app registration or managed identity with three values: the issuer set to your OIDC discovery URL, the subject set to the workload's exact SPIFFE ID, and the audience set to api://AzureADTokenExchange. At runtime the workload fetches a JWT-SVID scoped to that same audience and exchanges it for a Microsoft Entra access token using a client-assertion credential flow, then uses that token against Azure resources with no stored secret anywhere in the chain. If you also enforce Conditional Access policies on the receiving app registration, review them against zero-trust hardening guidance such as our [Entra ID Conditional Access hardening guide](/blog/how-to-harden-entra-id-conditional-access-zero-trust) so the federated credential inherits the same access restrictions as any other identity in the tenant.
7. Consider commercial SPIRE tooling for multi-cluster or mesh-integrated rollouts
Running SPIRE at scale across multiple clusters, clouds, or alongside a service mesh like Istio adds operational surface: federation between trust domains, certificate rotation at fleet scale, and mesh-native mTLS enforcement. Tetrate is one vendor offering commercial SPIRE-based tooling and support (including SPIRE-backed identity for Istio deployments through Tetrate Service Bridge) for teams that want vendor support around the open-source SPIRE project rather than operating it entirely in-house; evaluate this against your team's existing PKI and mesh operations capacity rather than defaulting to it.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Validation
Confirming that workloads are actually using short-lived SVIDs, and not silently falling back to a static credential you forgot to remove, requires checking both ends of the authentication flow.
Inspect issued SVIDs directly
Use the spire-server entry show command to confirm the registration entries and their TTLs match your intent, and inspect a live X.509-SVID's certificate validity window (typically minutes to a few hours) to confirm it is genuinely short-lived rather than a long-dated certificate that was manually pinned.
Force rotation and confirm the workload survives it
Let an SVID approach expiry, or manually trigger agent restart, and confirm the workload's connections to Vault or Azure resources continue uninterrupted because the Workload API delivered a fresh SVID transparently. A workload that errors out on rotation is not correctly integrated with the Workload API and is likely caching a credential past its intended lifetime.
Confirm the static credential is actually gone
After cutting a service over to SVID-based auth, revoke or disable the static credential it used previously (the old service account key, the old API key) rather than leaving it valid as a silent fallback. If the workload keeps working after the static credential is revoked, the migration is real; if it breaks, something is still using the old path.
Check Vault and Entra ID audit logs for the federated identity
Vault's audit log should show authentications against auth/spiffe with the workload's SPIFFE ID as the identity, not a static token or AppRole. Entra ID's sign-in logs should show the federated credential's token exchanges tied to the configured issuer and subject, confirming the trust relationship is being exercised as configured rather than sitting unused.
Failure cases and common pitfalls
Most SPIRE deployment failures trace back to a small set of recurring misconfigurations. Knowing them ahead of time turns a debugging session into a checklist.
Trust domain mismatch between server and agent
A SPIRE server and its agents can only operate within a single trust domain, and that trust domain must be configured identically on both sides. A typo or environment-specific override that leaves an agent pointed at a different trust domain string than its server causes attestation to fail outright, and the error is not always obvious from the agent logs alone.
Weak or default node attestation selectors
Node attestation is only as strong as the evidence it accepts. The deprecated Kubernetes k8s_sat attestor and other coarse-grained methods can allow one compromised node to attest as another if selectors are not scoped tightly; use k8s_psat (projected service account tokens) for Kubernetes deployments and verify that each node presents evidence unique to itself.
Insecure bootstrap left enabled past testing
SPIRE supports an insecure_bootstrap option that lets an agent skip validating the server's identity on first contact, intended only for local testing. Leaving this enabled in production means a man-in-the-middle attacker who can intercept the agent's first connection could impersonate the SPIRE server entirely. Confirm this is disabled before going live.
Federation trust domain and bundle endpoint misconfiguration
When federating two SPIRE trust domains (for a multi-cluster or multi-cloud deployment), each side must correctly fetch and refresh the other's trust bundle from its federation bundle endpoint. A stale or unreachable bundle endpoint causes cross-domain SVID validation to fail silently on one side while appearing to work on the other, which is a common source of confusing intermittent federation errors.
Signing algorithm mismatch with the federation target
SPIRE issues JWT-SVIDs signed with ES256 by default. Some relying parties, including Entra ID's external issuer support, require RS256-signed tokens instead. Discovering this after deploying the OIDC discovery provider means reconfiguring the server's CA key type and re-issuing everything downstream, so confirm the signing algorithm requirement of every federation target before the initial rollout, not after.
Rebootstrap failures after prolonged agent-server disconnection
If an agent cannot reach the server long enough for its cached trust bundle to go stale, or if the server is reinstalled without preserving continuity of its CA, the agent can lose trust entirely. With rebootstrap_mode set to never, this requires manual recovery rather than automatic re-bootstrapping, so monitor agent-to-server connectivity as a first-class operational signal, not an afterthought.
Security tradeoffs
SPIRE removes a real and persistent risk (standing static credentials with no built-in expiration) but it does so by introducing a new piece of security-critical infrastructure that must itself be operated correctly. This tradeoff is worth stating plainly rather than glossing over. Running a SPIRE server means running what is functionally a certificate authority: its signing key, its registration database, and its availability all become critical-path dependencies for every workload that depends on it for authentication. An outage in SPIRE server availability, or an agent that cannot reach it, can block legitimate workloads from authenticating anywhere downstream, a failure mode that a static, already-issued API key does not have. The operational burden also includes maintaining accurate registration entries as workloads are created and destroyed, since a stale registration either leaves a decommissioned workload with lingering trust or, worse, a new workload without the identity it needs. Multi-cluster or multi-cloud federation adds further complexity: each trust domain boundary is another place where a bundle endpoint, a signing algorithm, or a trust domain string can be misconfigured. Against that operational cost sits the risk it eliminates: a static credential's blast radius is bounded only by how long it takes someone to notice it leaked, which in practice is often months, whereas a compromised SVID with a lifetime measured in minutes to hours self-heals on its own schedule regardless of whether anyone notices the compromise at all. For teams running Kubernetes, a service mesh, or heterogeneous multi-cloud workloads at a scale where static credential sprawl is already a known problem, that tradeoff generally favors adopting SPIRE, provided the rollout is staged rather than forced, and provided the team treats SPIRE server operations with the same seriousness it would give any other internal certificate authority.
The bottom line
SPIFFE/SPIRE replaces long-lived static credentials with short-lived cryptographic workload identities issued at runtime, and it federates cleanly into HashiCorp Vault and Azure AD/Entra ID so existing secrets and cloud IAM infrastructure does not need to be replaced, only extended. This is a different, broader problem than the CI/CD-specific OIDC federation covered in our earlier guides: SPIRE is for every workload in your environment continuously, not just a build pipeline authenticating to a cloud provider at job execution time. Stage the rollout service by service, validate SVID issuance and rotation before decommissioning any static credential, and treat the SPIRE server itself with the operational rigor of an internal certificate authority, because that is what it is.
Frequently asked questions
What is the difference between SPIFFE and SPIRE?
SPIFFE is the open standard that defines how workload identities (SPIFFE IDs) and their credentials (SVIDs) should be formatted and issued. SPIRE is the reference implementation of that standard: the actual server and agent software that performs node and workload attestation and issues SVIDs to running workloads.
Is SPIFFE/SPIRE the same as the workload identity federation used for GitHub Actions or GitLab CI/CD?
No. CI/CD workload identity federation (covered in our earlier guides) is a narrower pattern where a build pipeline exchanges a short-lived OIDC token for cloud credentials at job execution time. SPIFFE/SPIRE is a general-purpose framework that issues identities continuously to any running workload, including services that never touch a CI/CD pipeline, and it can federate into multiple systems including Vault and cloud IAM providers rather than being tied to one cloud's OIDC trust relationship.
Do I need Kubernetes to run SPIRE?
No, but Kubernetes has the most mature, best-documented attestation path via the k8s_psat node attestor. SPIRE also supports node attestation on AWS EC2, Azure MSI, and GCP IIT, and join-token-based attestation for bare-metal or unsupported infrastructure, though the setup requires more manual configuration outside Kubernetes.
Can SPIRE and static credentials coexist during migration?
Yes, and this is the recommended approach rather than a big-bang cutover. Onboard one service or namespace to SVID-based authentication at a time, validate the flow end to end including rotation, and only then revoke the static credential that service previously used, repeating per service until migration is complete.
How does SPIRE federate with HashiCorp Vault?
Vault's SPIFFE auth method validates SVIDs issued by an external SPIFFE authority like SPIRE against a trusted bundle; it does not issue SPIFFE identities itself. A workload presents its JWT-SVID or X.509-SVID to Vault's auth/spiffe endpoint and receives a short-lived Vault token scoped to a policy in return, with SPIRE remaining the sole identity authority in the flow.
What has to change to federate SPIRE with Azure AD/Entra ID?
You must deploy the SPIRE OIDC discovery provider on a domain you control, enable the signing-key use parameter in its configuration, and reconfigure SPIRE's certificate authority to issue RS256-signed JWT-SVIDs since Entra ID does not accept SPIRE's default ES256 signing for this flow. You then add a federated identity credential in Entra ID specifying the OIDC discovery URL as issuer, the workload's SPIFFE ID as subject, and api://AzureADTokenExchange as audience.
Sources & references
- SPIFFE and SPIRE documentation
- SPIRE Concepts (node and workload attestation)
- Registering workloads with SPIRE
- Deploying a Federated SPIRE Architecture
- SPIFFE Federation specification (spiffe/spiffe GitHub)
- HashiCorp Vault SPIFFE auth method
- HashiCorp: Implementing workload identity with Vault and SPIFFE
- Microsoft Entra: Federate a SPIFFE/SPIRE workload identity
- SPIRE OIDC Discovery Provider (spiffe/spire GitHub)
- Tetrate: Why would you need SPIRE for authentication with Istio?
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.