SPIFFE & SPIRE.

What SPIFFE is

SPIFFE, the Secure Production Identity Framework For Everyone, is an open specification published by the SPIFFE project, a CNCF Graduated project as of 2022. It defines:

• A naming scheme for workload identities (the SPIFFE ID)
• Document formats for carrying those identities (SVIDs, X.509 or JWT)
• A protocol for issuing those documents to workloads (the Workload API)
• The concept of a trust domain, the scope within which a SPIFFE ID is meaningful and authoritative

The core idea is that a workload, a process running somewhere, should authenticate itself not by presenting a shared secret (which can leak, can be copied, can outlive its purpose) but by presenting cryptographic evidence tied to its runtime. SPIFFE defines how that evidence is structured. SPIRE, the SPIFFE Runtime Environment, is the reference implementation that actually delivers SVIDs to workloads.

Why it matters for NHI

SPIFFE/SPIRE addresses several of the OWASP NHI Top 10 risks simultaneously:

• NHI2 (Secret leakage): there is no shared secret to leak. The workload's identity credential (SVID) is issued fresh, short-lived, and memory-resident.
• NHI4 (Insecure authentication): mTLS via X.509-SVIDs is a modern, properly-authenticated pattern.
• NHI7 (Long-lived secrets): SVIDs typically have TTLs measured in hours. Rotation is automatic.
• NHI8 (Environment isolation): trust domains separate environments by construction.
• NHI9 (NHI reuse): each workload has its own SPIFFE ID; identity is workload-specific.

SPIFFE IDs and trust domains

A SPIFFE ID is a URI that identifies a workload. It has the form:

spiffe://trust-domain/workload-path

For example: spiffe://prod.example.com/ns/finance/sa/invoicer. The trust domain (prod.example.com) is the scope of issuance authority, a SPIRE server is the authoritative source for SPIFFE IDs under that domain. The workload path is organisation-defined and typically encodes the workload's namespace and service account or equivalent.

Trust domains are significant architectural units: they partition the identity issuance authority. Most organisations run one trust domain per environment (prod, staging, dev) or one per organisational unit, federated where cross-domain trust is needed.

SVIDs, SPIFFE Verifiable Identity Documents

An SVID is the artefact a workload presents to prove its identity. Two forms:

• X.509-SVID: an X.509 certificate where the SPIFFE ID appears in the URI Subject Alternative Name field. Used for mTLS.
• JWT-SVID: a JWT with the SPIFFE ID in the sub claim. Used for application-layer authentication where mTLS is not available.

SVIDs are issued with short TTLs, typically one hour, and rotated transparently by the SPIRE agent running alongside the workload. The workload consumes SVIDs through the Workload API (a Unix domain socket or gRPC endpoint exposed by the local SPIRE agent).

Node and workload attestation

SPIRE's defining feature is attestation, the process by which the SPIRE server verifies that a workload requesting an SVID is actually who it claims to be. Attestation happens in two layers:

• Node attestation: the SPIRE agent, running on the node, proves to the SPIRE server that it is legitimately running on the expected infrastructure. Node attestor plugins exist for AWS IID, AWS IAM, GCP IIT, Azure MSI, Kubernetes PSAT, Docker, TPM, and custom environments.
• Workload attestation: the SPIRE agent, having been attested, attests each local workload based on properties the infrastructure exposes, process metadata (UID, GID, executable path), Kubernetes pod labels, Docker container labels, etc.

The combined attestation path means the SPIRE server issues an SVID to a workload only when both the node and the workload itself match registered selectors. There is no shared credential at any point, the proof is infrastructural.

SPIRE architecture at a glance

• SPIRE server: the trust-domain authority. Holds the signing key material for the trust domain. Manages the registry of authorised workload entries.
• SPIRE agent: runs on each node. Attests to the server, then attests local workloads, then delivers SVIDs via the Workload API.
• Workload API: the gRPC interface through which workloads request SVIDs. Exposed locally by the agent.
• Registration entries: the set of rules that say "a workload matching these selectors should receive an SVID with this SPIFFE ID."

Common deployment patterns

• Kubernetes: SPIRE deployed as a StatefulSet (server) + DaemonSet (agent). Workload attestation via PSAT (projected service account tokens). Typical day-one deployment for CNCF-shop-style organisations.
• Service mesh integration: Istio, Linkerd, and Consul can all use SPIFFE IDs as the underlying identity primitive for mesh mTLS. In some configurations the mesh's own sidecar fetches SVIDs from SPIRE.
• Multi-cloud: one trust domain per cloud, federated via SPIFFE Federation (the mechanism by which two trust domains recognise each other's SVIDs).
• Edge workloads / VMs: SPIRE agent deployed on the host, attesting via TPM or cloud-native instance identity mechanisms.

Production considerations

• HA SPIRE server: SPIRE server supports high availability via shared datastore (typically Postgres). Treat the SPIRE server as the PKI for your workload identity, the same operational rigour applies.
• Trust domain strategy: decide early. Merging trust domains later is hard. One per environment is a reasonable starting point.
• Registration automation: manual registration doesn't scale. Integrate with your IaC so that workload-to-SPIFFE-ID mappings are declarative.
• TTL tuning: default 1-hour TTL is a good starting point. Shorter TTLs reduce revocation exposure; longer TTLs reduce control-plane load.
• Observability: SPIRE emits Prometheus metrics; alert on SVID issuance failures, agent disconnects, and unexpected registration changes.

Relationship to IETF WIMSE

SPIFFE is a deployable open-source specification maintained by the CNCF SPIFFE project. WIMSE (Workload Identity in Multi-System Environments) is a newer IETF working group formalising related concepts at the protocol level. The two are complementary: many of WIMSE's draft documents explicitly reference SPIFFE constructs, and SPIFFE is the most mature production implementation of the patterns WIMSE is standardising.

For the moment, most practitioners treat SPIFFE/SPIRE as the production system and watch WIMSE as it matures. See our WIMSE page for the standards-track view.

Frequently asked questions

What is SPIFFE?

SPIFFE (Secure Production Identity Framework For Everyone) is an open standard for giving workloads cryptographic identities that are derived from the runtime rather than issued as static secrets. A workload proves what it is through attestation, and receives a short-lived credential called an SVID. SPIRE is the reference implementation. It is a CNCF project and is the most widely deployed answer to workload identity in production today.

What is an SVID?

An SVID is a SPIFFE Verifiable Identity Document: the credential a workload receives after attestation. It comes in two forms, an X.509 certificate or a JWT, and it encodes a SPIFFE ID of the form spiffe://trust-domain/workload-path. SVIDs are deliberately short-lived, typically minutes to hours, so that theft has a bounded window and rotation is continuous rather than an event.

What is the difference between SPIFFE and SPIRE?

SPIFFE is the specification: the identity format, the SVID document types, and the Workload API that workloads call to obtain credentials. SPIRE is the production implementation of that specification, providing the server, the node and workload attestation plugins, and the registration model. You adopt SPIFFE as a design and usually run SPIRE to deliver it, though other implementations exist including managed offerings from cloud providers and service meshes.

What is a SPIFFE trust domain?

A trust domain is the boundary within which a SPIFFE ID is unique and within which credentials are issued under a common authority. It appears as the authority component of a SPIFFE ID, for example spiffe://prod.example.com/service/payments. Federating two trust domains lets workloads in each authenticate to the other without merging their issuance authorities, which is how multi-cloud and cross-organisation workload authentication is normally structured.

How does SPIFFE work with Istio or a service mesh?

Service meshes were among the earliest large-scale SPIFFE consumers. Istio issues SPIFFE-format identities to sidecars and uses them for mutual TLS between services, so mesh-internal traffic is authenticated by workload identity rather than by network position. If you already run a mesh you may have SPIFFE identities without having adopted SPIFFE deliberately, which is worth checking before starting a separate workload identity project.

Should we deploy SPIFFE now or wait for the IETF WIMSE standard?

Deploy now. WIMSE is entirely at Internet-Draft stage with no RFC and no published timeline, and it is being designed so that SPIFFE deployments are a reachable migration path rather than a dead end. Waiting means continuing to run static long-lived secrets for an indefinite period in exchange for no benefit. See our page on IETF WIMSE for the current draft family and status.

Does SPIFFE work outside Kubernetes?

Yes. SPIRE ships attestation plugins for cloud compute instances, bare metal, and Unix processes as well as Kubernetes, and it is regularly used for virtual machines and on-premise workloads. Kubernetes is the most common starting point because its projected service account tokens make attestation straightforward, but the model does not depend on it.