SPIRE, the SPIFFE Runtime Environment, is a system that gives every workload a cryptographic identity and keeps the keys behind it short-lived and rotated. It implements SPIFFE, the Secure Production Identity Framework for Everyone, a set of open specifications that define a workload identity as a URI called a SPIFFE ID and a verifiable document called an SVID, either an X.509 certificate or a JWT. Instead of baking long-lived passwords, API keys or static certificates into images and configuration, a workload asks a local agent for its identity, and SPIRE issues it only after attesting what the workload is and where it runs. This is the key-management problem at the heart of zero trust: identity material that is issued automatically, scoped to one workload and replaced every hour or so. SPIFFE and SPIRE entered the CNCF Sandbox in 2018, moved to Incubating in 2020, and were announced as graduated on September 20, 2022. The 1.14 line is current.
CNCF daily · Sprint 1, day 6 · Key Management
At a glance
| Category | Key Management |
| CNCF status | Graduated. Sandbox 2018; Incubating 2020; graduation announced September 20, 2022, together with SPIFFE |
| Written in | Go |
| License | Apache 2.0 |
| Standard | SPIFFE: SPIFFE ID, X.509-SVID, JWT-SVID, Workload API and trust bundles |
| Main components | SPIRE Server, SPIRE Agent, plugins for attestation, key storage and upstream authorities |
| Platforms | Kubernetes, AWS, GCP, Azure, bare metal and virtual machines |
| Integrations | Envoy, gRPC, Istio, Kubernetes, Sigstore and Tekton |
| Release line | 1.14 (patch releases through 2026); 1.13 also published |
Architecture
flowchart TB
subgraph TD[Trust domain example.org]
SRV[SPIRE Server<br/>CA, registration entries, datastore] --> DB[(Datastore<br/>PostgreSQL or MySQL)]
SRV -->|optional| UP[Upstream authority<br/>Vault, cert-manager, cloud CA]
end
subgraph NODE[Each node]
AG[SPIRE Agent<br/>node attestation and cache]
WL[Workload<br/>service or pod]
end
AG -->|node attestation<br/>Kubernetes, AWS, GCP, Azure| SRV
WL -->|Workload API<br/>Unix socket| AG
AG -->|workload attestation<br/>pod, process, container| WL
SRV -->|signs SVIDs| AG
AG -->|X.509 or JWT SVID and bundle| WL
WL -->|mutual TLS with SVIDs| PEER[Peer service or Envoy proxy]
SRV -->|federated trust bundles| OTHER[Other trust domain]
| Component | Responsibility |
|---|---|
| SPIRE Server | Acts as the certificate authority for a trust domain, holds registration entries that map selectors to SPIFFE IDs, and signs SVIDs for attested agents and workloads. |
| SPIRE Agent | Runs on each node, attests itself to the server, then attests local workloads and delivers their SVIDs through the Workload API. |
| Node attestation | Proves a node’s identity using platform evidence, such as a Kubernetes projected service account token or a cloud instance identity document. |
| Workload attestation | Identifies a calling process by selectors such as the Kubernetes namespace, service account and pod labels, or Unix user, so no secret is handed to the workload. |
| SVID | A short-lived X.509 certificate or JWT that carries the SPIFFE ID. Both are rotated automatically before expiry. |
| Registration entries | Policy that says which selectors receive which SPIFFE ID, managed through the API or the SPIRE controller manager on Kubernetes. |
| Federation | Exchange of trust bundles between trust domains, so workloads in separate clusters or organisations can verify each other. |
| Plugins | Replaceable pieces for attestors, the datastore, key management and the upstream authority that anchors SPIRE under an existing CA. |
Design principle. SPIRE issues identity based on attested properties of the workload rather than on a secret it carries. Because SVIDs are short-lived and delivered over a local socket, there is no long-lived credential to leak, and rotation is a routine event instead of an incident. The SPIFFE standard keeps the identity portable, so the same identity works for mutual TLS in a mesh, for signing requests, and for authenticating to external systems.
Production reference design
A common pattern on EKS, GKE, AKS or on-premises Kubernetes: one SPIRE trust domain per environment, with Envoy or a service mesh using the SVIDs for mutual TLS.
- Choose the trust domain and topology. Pick a trust domain name, such as
prod.example.org, and decide between a single server cluster and nested servers for multiple clusters. Run the server highly available with an external PostgreSQL or MySQL datastore rather than the default SQLite. - Install with the hardened Helm charts, which bundle the server, agent, the CSI driver and the controller manager:
Check chart names and values against the chart version you install.helm repo add spiffe https://spiffe.github.io/helm-charts-hardened/ helm install spire-crds spiffe/spire-crds -n spire-mgmt --create-namespace helm install spire spiffe/spire -n spire-mgmt \ --set global.spire.trustDomain=prod.example.org - Anchor the CA correctly. Use an upstream authority plugin, such as Vault or cert-manager, so SPIRE’s signing certificate chains to a root you control, and keep the root key outside the cluster.
- Register workloads. On Kubernetes, declare identities as resources and let the controller manager create the entries:
apiVersion: spire.spiffe.io/v1alpha1 kind: ClusterSPIFFEID metadata: { name: orders } spec: spiffeIDTemplate: "spiffe://prod.example.org/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}" podSelector: { matchLabels: { app: orders } } namespaceSelector: { matchLabels: { spiffe: enabled } } - Consume the identity. Mount the Workload API socket with the SPIFFE CSI driver and let Envoy fetch its certificates through the Secret Discovery Service, or use a SPIFFE library in the application. Authorise calls by SPIFFE ID in Envoy or in the application.
- Federate where needed. Exchange trust bundles between trust domains so that clusters in separate environments, or partner systems, can verify each other without a shared CA.
- Monitor and rotate. Scrape SPIRE telemetry with Prometheus, alert on attestation failures and approaching CA expiry, and rehearse CA rotation before it is needed.
Typical production uses include mutual TLS between services, replacing static credentials for access to databases and cloud APIs, identity for CI pipelines, signing and verifying software artifacts, and a common identity layer across clusters and clouds.
Operational considerations
- The server is a critical dependency. Run it highly available with a durable datastore, back up the data and keys, and test recovery. Agents keep serving cached SVIDs through short outages, but new identities and rotations depend on the server.
- Protect the signing key. The CA key defines trust for the whole domain. Use a key manager or an upstream CA, restrict access to the server, and plan rotation of the signing certificate.
- Design registration carefully. Identity policy lives in registration entries and selectors. Overly broad selectors let unrelated workloads claim the same identity, so scope by namespace and service account.
- Mind attestation limits. Attestation is only as strong as the platform evidence behind it. On shared nodes, workload selectors depend on the node’s integrity, so harden the nodes and restrict the Workload API socket.
- Upgrade in order. Upgrade servers before agents, read the release notes for each minor version, and keep the supported two or three recent minor versions.
- Budget for adoption effort. Workloads must consume SVIDs, through a mesh, a proxy or a library. Planning that integration is most of the work, not the SPIRE install.
Adoption
- The CNCF graduation announcement named end users including Anthem, GitHub, Netflix, Niantic, Pinterest and Uber, and the summary lists Bloomberg, ByteDance, Pinterest and Twilio.
- Uber described SPIFFE as the foundation of securing production interactions, ByteDance reported a zero trust infrastructure securing hundreds of thousands of workloads, and Indeed and Carelon Digital Platforms use it as a common zero trust layer. HPE and Cray use SPIRE in system management tooling for exascale supercomputers.
- The projects completed a TAG Security review in 2020 and a third-party audit by Cure53, which concluded that SPIRE is a secure project created with security in mind. SPIFFE integrates with Envoy, gRPC, Istio, Kubernetes, Sigstore and Tekton.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| cert-manager | Kubernetes certificate controller for TLS certificates | Ingress and service certificates from an existing CA, often used together with SPIRE as an upstream authority |
| HashiCorp Vault PKI and secrets | Central secrets and certificate authority with APIs | Organisations that already run Vault and want dynamic secrets and a CA |
| Istio, Linkerd and other meshes with built-in CAs | Mesh-managed workload certificates | Teams that only need mutual TLS inside one mesh |
| Cloud workload identity (AWS IAM roles, GCP Workload Identity, Azure managed identity) | Provider-native identity for cloud APIs | Access to one cloud’s APIs, not portable across providers |
| Static secrets and long-lived certificates | Manually issued credentials | Small or legacy systems, with the risk of leakage and manual rotation |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| Short-lived, automatically rotated identities with no secrets baked into workloads | Another critical control plane to run, secure and upgrade |
| Strong attestation of platform and workload, not just a token | Workloads must be adapted, directly or through a proxy, to consume SVIDs |
| Open SPIFFE standard that works across clouds, clusters and vendors | Registration and selector design needs care and governance |
| Federation across trust domains | Operating the CA, upstream authority and rotation takes expertise |
| Graduated project with a third-party security audit and a large integration ecosystem | A heavier solution than a mesh’s built-in CA when only intra-mesh mutual TLS is required |
Recommendation
Adopt SPIRE where workloads span several clusters, clouds or runtimes and you need a portable, short-lived identity for mutual TLS and for replacing static credentials. Run the server highly available, anchor it under a CA you control, and integrate through Envoy or a mesh before moving applications. Assess a mesh’s built-in CA or cert-manager first if all you need is mutual TLS inside one cluster.
References: CNCF project page · CNCF: SPIFFE and SPIRE graduation announcement · SPIFFE and SPIRE documentation · SPIRE hardened Helm charts · SPIRE on GitHub