SPIFFE / SPIRE

What SPIFFE and SPIRE are

SPIFFE — the Secure Production Identity Framework for Everyone — is a set of open standards, hosted by the CNCF, that defines how software workloads should identify themselves to one another. It does not care what your CA hierarchy looks like, what orchestrator you run, or what programming language your services are written in. It defines three things:

1. A URI-shaped identity called a SPIFFE ID (e.g. spiffe://prod.example.com/service/payments).
2. Two documents that carry that identity — the X.509 SVID (a certificate whose SAN is the SPIFFE ID) and the JWT SVID (a JWT whose sub is the SPIFFE ID).
3. The Workload API, a local Unix socket that a workload asks for its identity on, no matter what platform it runs on.

SPIRE — the SPIFFE Runtime Environment — is the reference server-plus-agent implementation. A SPIRE Server signs SVIDs; SPIRE Agents run on each node, verify the identity of the workload asking for a credential (via kernel-level attestation), and hand back the appropriate SVID. Alternative implementations exist (Istio, HashiCorp Consul, cert-manager's csi-spiffe driver), but SPIRE is the canonical one.

The core idea

Traditional service-to-service authentication uses secrets — a bearer token, an API key, a password — that both sides know. That means the secret gets stored somewhere (config file, secret manager, env var), copied to each service that needs it, and rotated on a manual cadence. It is a supply chain of secrets with many failure modes.

SPIFFE replaces "who has the shared secret?" with "who is this workload, cryptographically?" Every workload gets a short-lived cert (default validity is often measured in hours) whose SAN identifies exactly what it is in the platform. Other workloads verify the presented SVID against a trust bundle — no shared secrets involved.

The key mechanism is workload attestation. Before the SPIRE Agent hands a workload its SVID, it verifies the workload's identity through platform-native means:

The Agent asks the kernel who is on the other end of the Unix socket, ties that to a platform-native identity, and looks up which SPIFFE ID and SVID that identity is entitled to. This means the workload never has to possess a credential to receive one — the entitlement is proved by where and what it is, not by what it holds.

A concrete example

A payments service running in Kubernetes:

1. Container starts, connects to the local Workload API Unix socket at /tmp/spire-agent/public/api.sock.
2. SPIRE Agent reads the connecting process's PID, resolves it to a Kubernetes pod (namespace=prod, serviceAccount=payments, image=registry.example.com/payments@sha256:abc).
3. Agent looks up the registration entry: "pods matching these selectors get SPIFFE ID spiffe://prod.example.com/service/payments."
4. Agent asks SPIRE Server to issue an X.509 SVID for that ID.
5. Agent streams the SVID back to the workload plus the trust bundle needed to verify peer SVIDs.
6. Workload uses the SVID for outbound mTLS to other services.
7. Before the SVID expires, Agent hands the workload a fresh one via the same open stream — no re-authentication required.

The whole flow takes milliseconds. Rotation is transparent.

What problem it solves

SPIFFE addresses three chronic pain points of workload authentication:

1. Shared secret sprawl. No API keys copied into config files. No passwords stored in vaults just to be read by services that could have used a certificate. The workload's identity is bootstrapped from platform-native attestation, not from a pre-existing secret.
2. Rotation friction. SVIDs are short-lived by design — often 1-24 hours. Rotation is continuous, not a scheduled event, so there is no "renewal deadline" that could be missed.
3. Cross-platform identity. A workload in Kubernetes, a workload on a VM, and a workload in a cloud function all get the same shape of identity from the same API. Federation between trust domains is a first-class part of the spec.

For platform teams, the concrete outcome is: no more "which service uses which token" spreadsheets, no more secret rotation runbooks, no more mTLS certificates issued by a bespoke internal script that broke last Thursday.

When to use SPIFFE

SPIFFE is a strong fit when:

• You run Kubernetes, service meshes, or multi-cluster / multi-cloud workloads and need service-to-service mTLS.
• You want to eliminate shared secrets between services.
• You need cross-platform workload identity (K8s + VMs + serverless).
• You are adopting zero-trust and need a workload identity substrate under it.
• You are federating trust between organisations (partner integrations, multi-tenant SaaS).

It is not the right fit when:

• You need long-lived device certificates for IoT — use X.509 CLM or IDevID/LDevID instead.
• You need public TLS certificates — SPIFFE issues internal identities, not WebPKI certs.
• You need code signing or document signing — different signature semantics, different lifetimes.

SPIFFE and SPIRE ecosystem

The standards themselves are versioned separately from any implementation. The current SPIFFE spec versions are at https://github.com/spiffe/spiffe/tree/main/standards.

Common misconceptions

"SPIFFE is a service mesh." It is not. Service meshes (Istio, Linkerd, Consul) use SPIFFE identities but SPIFFE itself is just the identity layer. You can use SPIFFE without a mesh and a mesh without SPIFFE.

"SPIRE is only for Kubernetes." SPIRE runs on VMs, bare metal, and cloud functions too. Kubernetes is the most common deployment but not the only one.

"SPIFFE IDs are secrets." They are not — an SVID's SAN is public. What matters is possession of the SVID's private key, which stays on the workload.

"SPIFFE replaces public PKI." It does not. SPIFFE is for internal workload identity. Your public-facing TLS still needs certs from a public CA (or your ACME-integrated internal CA for internal-only web services).

"An X.509 SVID looks weird — is it really a normal certificate?" It is a standard X.509 certificate with a specific SAN URI shape. Every TLS library validates it exactly the same way as any other cert. The only "SPIFFE-specific" thing is that the SAN happens to be a spiffe:// URI.

How TigerTrust interacts with SPIFFE

TigerTrust treats SPIFFE identities as first-class machine identities in its inventory. When a customer runs SPIRE (or an equivalent SVID issuer), TigerTrust can discover the issued SVIDs, tie them back to their originating trust domain, and include them in the same governance framework as X.509 host certs, SSH keys, IoT device certs, and TPM-bound identities. For customers running Kubernetes-native issuance via cert-manager, TigerTrust's Kubernetes CLM covers the same lifecycle mechanics for both SPIFFE SVIDs and cert-manager-issued workload certs — one platform, one inventory, one audit trail. See Kubernetes CLM for detail.

Related reading

• SPIFFE Specification: https://github.com/spiffe/spiffe
• SPIRE project: https://spiffe.io/docs/latest/spire-about/
• CNCF SPIFFE / SPIRE case studies: https://spiffe.io/community/adopters/