SPIFFE/SPIRE Workload Identity Without Secrets

Q: What is the difference between SPIFFE and SPIRE?

SPIFFE, the Secure Production Identity Framework for Everyone, is a set of open standards: the SPIFFE ID (a URI of the form spiffe://trust-domain/path), the SVID (a verifiable identity document, today an X.509 certificate or a JWT, with a proof-of-possession WIT-SVID incubating), the trust bundle that holds a domain's public keys, the Workload API through which a process obtains its SVID without presenting any credential, and the federation specification for trusting other domains. SPIRE, the SPIFFE Runtime Environment, is the reference implementation: a server that acts as the certificate authority and holds registration entries, and an agent on every node that attests the node to the server, attests each workload process that connects to its local Unix socket, and serves the matching SVID. Other systems implement SPIFFE too, notably service meshes such as Istio, which issue SPIFFE-formatted identities from their own CA; SPIRE is what you run when you want one implementation across all of your infrastructure rather than one per platform.

Q: How does a workload get its SVID from SPIRE without any bootstrap secret?

It connects to the SPIRE agent's Workload API over a local Unix domain socket and asks. The credential is the fact of being a process the kernel can identify: the agent takes the caller's process ID, asks the operating system and, on Kubernetes, the kubelet and container runtime what that process is, and produces selectors such as the namespace, service account, container image digest, Unix user ID, systemd unit or Slurm job. It compares those selectors against the registration entries the server sent it for this node and, if an entry matches, returns the SVID it already holds in its cache along with the trust bundle. There is no token in a file, no environment variable and no API key, which is why nothing can be leaked in a crash dump or a log. The agent itself obtained its identity through node attestation, using evidence such as an AWS instance identity document, a Kubernetes projected service account token or a TPM certificate that the server verifies out of band with the cloud API, the kube-apiserver or the DevID CA.

Q: What are the default SVID and CA lifetimes in SPIRE and should I change them?

The SPIRE server defaults are a 1-hour X509-SVID, a 5-minute JWT-SVID, and a 24-hour CA signing key TTL using an EC P-256 key; the agent SVID defaults to the same TTL as the X509-SVID. The agent rotates X509-SVIDs at half their lifetime by default, so a 1-hour certificate is renewed every 30 minutes and a workload that streams updates from the Workload API sees the new certificate long before expiry. You should not lengthen SVID TTLs to reduce load, because issuance is cheap and cached at the agent while a longer TTL only extends how long a stolen SVID remains valid. If what you actually want is to survive SPIRE server downtime, set the agent's availability_target, which must be at least 24 hours and requires the SVID lifetime to leave a grace period of at least 12 hours; the agent then rotates when the remaining lifetime reaches the target rather than at the half-life, so it keeps serving valid identities through an outage of that length. JWT-SVIDs are not affected by the availability target.

Q: When should I use cloud-native workload identity instead of SPIRE?

When every workload that needs the identity runs inside one platform and only needs to talk to that platform's services. AWS IAM Roles for Service Accounts and Pod Identity, GCP Workload Identity Federation and Azure Managed Identity attest the compute the cloud manages and hand out temporary credentials for that cloud's APIs with no bootstrap secret, and in that setting SPIRE adds an operational burden without adding assurance. SPIRE earns its place when identity must be uniform across platforms: pods in several clusters, VMs, bare metal with TPMs, CI runners, GPU cluster jobs and partner organisations, all in one trust domain with one registry and one audit trail. It also matters when peers need attestation stronger than a service account, such as an image digest selector for a workload that touches money, or when identities must be verifiable by third parties through federation. The two approaches compose: a SPIRE-attested workload on-prem can exchange a JWT-SVID for temporary cloud credentials through OIDC federation, which is how the last static access key leaves the estate.

Q: How does SPIRE integrate with Istio or another service mesh?

Through Envoy's Secret Discovery Service. Istio detects a Unix domain socket that implements the SDS API on a defined path, and if the SPIRE agent's socket is mounted into the proxy through the SPIFFE CSI driver, Envoy fetches its certificate and trust bundle from SPIRE rather than from istiod. Both projects strongly recommend the CSI driver over a hostPath mount, because a broad host mount exposes the Workload API to processes you never registered. Workloads are registered automatically by the SPIRE Controller Manager using a ClusterSPIFFEID resource whose template typically produces spiffe://trust-domain/ns/namespace/sa/service-account, with workload selector templates on namespace and service account. The result is that the mesh's identity and the non-mesh identity for VMs, batch jobs and CI become the same identity, and an authorization policy written on SPIFFE IDs applies to all of them. The integration is orthogonal to the sidecar-versus-ambient decision; it changes where certificates come from, not how traffic is intercepted.

Q: What is SPIFFE federation and what does it not do?

Federation lets two trust domains, typically two organisations, verify each other's SVIDs. Each SPIRE server exposes a bundle endpoint that serves its trust bundle over HTTPS, and each side periodically fetches the other's bundle and stores it as a foreign trust domain. SPIRE supports two endpoint profiles: https_web, where the endpoint presents a certificate from a public CA, optionally obtained via ACME, and https_spiffe, where the endpoint presents its own SVID and the fetching side pins the foreign domain's initial bundle out of band. Workloads that need to accept the foreign domain are registered with a federates-with list so they receive its bundle. What federation does not do is make the foreign domain's issuance decisions trustworthy: trusting spiffe://partner.example means trusting whatever node and workload attestors the partner runs and however broadly they register entries, so the attestation requirements belong in the written agreement. Nor does federation authorise anything; it only lets a peer authenticate a foreign identity, after which your own policy decides what that identity may do.

Q: What is a WIT-SVID and why is it being added alongside X509-SVID and JWT-SVID?

The WIT-SVID is an incubating SPIFFE identity document format based on JOSE, aligned with the Workload Identity Token from the IETF WIMSE working group. Its distinguishing property is mandatory proof of possession: the token carries a confirmation claim binding it to a key the workload holds, so presenting the token is not enough, the presenter must also prove control of that key. That addresses the main weakness of JWT-SVIDs, which are bearer tokens: anything that captures one can replay it for its remaining lifetime, which is why SPIRE defaults JWT-SVIDs to five minutes. X509-SVIDs already have proof of possession through the TLS handshake, but they are awkward for HTTP-level and cross-organisation flows, API gateways and agent-to-agent calls where a token travels through intermediaries. SPIRE v1.15 shipped incremental WIT-SVID support in its SVID API client and bundle handling. For 2026 designs the practical guidance is unchanged: X.509 for the data plane, JWT for OIDC federation into other systems, and WIT-SVID evaluated for token-shaped flows as the standard leaves incubation.

Q: What are the most common SPIRE deployment mistakes?

The first is join tokens in production: a human-issued bootstrap secret for the agent recreates the long-lived credential at the root of the trust chain, when a platform attestor such as aws_iid, gcp_iit, azure_msi, k8s_psat, tpm_devid or x509pop would let the server verify the node against something external. The second is overly broad registration entries, typically a namespace-only selector, so every pod in the namespace, including an attacker's debug pod, receives the same identity; entries should require the service account and, for sensitive workloads, the image digest. The third is mounting the Workload API socket with a hostPath so that any process on the node can be attested, rather than using the SPIFFE CSI driver. The fourth is lengthening SVID TTLs to reduce load, which extends the value of a stolen credential without reducing any real load, when availability_target is the correct knob for outage tolerance. Others include treating the server datastore as disposable rather than as the CA's registry, hand-editing entries instead of declaring them from source, using SPIFFE IDs as an authorisation model rather than an authentication one, and deploying SPIRE without retiring the static secrets it was meant to replace.

Satyam Kumar

返回博客

cyber-security-patterns

SPIFFE/SPIRE: Workload Identity Without Long-Lived Secrets, and the Attestation Chain That Makes It Real (2026)

By Satyam KumarSeptember 8, 202620 min read

spiffe spire workload identity mtls x509-svid jwt-svid node attestation workload attestation spiffe federation istio spire integration service mesh identity non-human identity zero trust architecture kubernetes workload identity wit-svid wimse short-lived certificates

SPIFFE/SPIRE: Workload Identity Without Long-Lived Secrets, and the Attestation Chain That Makes It Real (2026)

Frequently Asked Questions

分享这篇文章

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

人工智能和云架构师。帮助团队构建可扩展到数百万的系统。

LinkedIn GitHub

SPIFFE/SPIRE: Workload Identity Without Long-Lived Secrets, and the Attestation Chain That Makes It Real (2026)

Frequently Asked Questions

分享这篇文章

Comments

Leave a comment