SPIFFE and SPIRE: How Workload Identity Works

When services run across containers, virtual machines, clusters, and cloud accounts, identifying one another by IP address or a shared secret becomes brittle. SPIFFE and SPIRE workload identity offer a way to give software workloads verifiable identities and short-lived credentials without tying those identities to a particular network location. This explainer is for platform engineers, security teams, and developers designing service-to-service trust.

What Are SPIFFE and SPIRE?

SPIFFE is an open set of specifications for identifying software systems, called workloads. It defines the SPIFFE ID format, credential documents called SPIFFE Verifiable Identity Documents (SVIDs), and the Workload API through which a workload can obtain its identity and credentials. A SPIFFE ID is a URI such as spiffe://example.org/ns/payments/sa/api: the trust domain names the authority, while the path describes the workload within it.

SPIRE is a production-ready implementation of SPIFFE. It verifies the environment in which an agent and workload are running, maps those verified properties to an identity, and makes the corresponding SVID available through the Workload API. SPIFFE describes interoperable interfaces and formats; SPIRE supplies a system for operating them.

For TLS applications, an X.509 SVID carries a SPIFFE ID in a certificate URI Subject Alternative Name. The SPIFFE overview describes the specifications and identity model. The IETF guidance for service identity in TLS covers how clients verify service identities in TLS generally; it does not define SPIFFE, but gives useful context for why identity validation is distinct from simply encrypting a connection.

Why Workload Identity Exists

Applications need credentials to prove which service is connecting. A common starting point is a static API key, a mounted certificate, or a username and password stored in a secret manager. These credentials can work, but they create lifecycle and distribution problems: teams must provision them, limit their scope, rotate them, and remove them when workloads disappear. Long-lived secrets may also be copied into images, logs, build systems, or developer environments.

Network addresses do not solve identity. A pod can be rescheduled and receive a different IP; a new workload may later reuse an old address. A hostname or namespace can help locate a service, but neither alone proves that the process using it is authorized. In a multi-cluster or hybrid environment, the same service may run on different infrastructure and still need a consistent identity.

SPIFFE separates identity from these deployment details. A relying service can authorize a stable SPIFFE ID, while an issuing system verifies the workload using evidence from its runtime. Short-lived SVIDs reduce the time window in which a leaked credential can be used, and automated rotation avoids requiring an operator to distribute a permanent secret to each instance.

How SPIFFE and SPIRE Work

The overall flow has several distinct trust steps:

1. Establish a trust domain. Operators choose a trust-domain name, such as example.org, and configure the authority that will issue identities and publish trust bundles.
2. Verify the node. A SPIRE server registers or otherwise trusts agents using a node-attestation method. For example, a Kubernetes deployment can use the Kubernetes API and a projected service-account token to verify an agent and its cluster.
3. Verify the workload. The SPIRE agent observes local workloads and gathers runtime-specific selectors, such as a Kubernetes namespace and service account. A registration entry says which verified selectors may receive a particular SPIFFE ID.
4. Issue an SVID. The server authorizes the identity, and the agent obtains or renews a credential for the workload. The workload asks through the local Workload API rather than handling the SPIRE server’s administrative credentials.
5. Authenticate a connection. A client presents its SVID during a protocol handshake, commonly mutual TLS. The server validates the certificate chain against a trusted bundle and checks the SPIFFE ID against its authorization policy.
6. Refresh and revoke trust. SVIDs are short-lived and can be rotated automatically. Trust bundles distribute the public trust material peers need to validate credentials; operators still need processes for changing trust domains and responding to compromise.

This chain matters: encryption alone does not identify an authorized caller. TLS protects traffic in transit, while certificate validation and application policy determine whether the peer’s identity is trusted and permitted to perform an action.

Identity federation is a separate configuration step, not an automatic consequence of using SPIFFE IDs. Two trust domains must exchange and manage trust bundles, and each side must define which identities from the other domain are accepted. Treat bundle distribution and trust-domain changes as security-sensitive operations: trusting an unfamiliar bundle can make credentials from another authority appear valid.

Components and Identity Formats

SPIFFE and SPIRE cover related but different layers:

The main SPIFFE credential forms solve different protocol needs:

The Workload API lets an authorized local workload retrieve SVIDs and trust bundles, and can notify clients when material changes. A SPIRE server stores trust-domain and registration state. SPIRE agents run near workloads, attest their environment, and expose a local API socket. Registration entries bind an identity to selectors and a parent agent; they are an authorization boundary and must not grant broad identities to loosely defined workloads.

The local socket is part of the security boundary. The agent must be able to establish which process is asking, and deployment permissions must prevent unrelated containers or users from reading another workload’s credentials. Selectors should describe the intended workload narrowly and be reviewed when namespaces, service accounts, or runtime labels change. A credential is only as trustworthy as both the attestation signal and the policy that maps that signal to an identity.

Real-World Uses

• Service-to-service authentication: Give APIs and background workers distinct identities for mutual TLS and policy decisions instead of sharing one cluster-wide certificate.
• Multi-cluster platforms: Let services authenticate across clusters using configured federation and trust bundles, without assuming that a private network implies trust.
• VM and container environments: Apply the same SPIFFE identity format to workloads running on different infrastructure, while using appropriate attestation methods for each platform.
• Secret delivery: Issue an identity that a secret manager can verify before releasing a narrowly scoped secret. SPIFFE does not itself replace a secret store or decide which data a workload may read.
• Mesh and non-mesh systems: Use workload identity in service meshes or in applications that call the Workload API directly. A mesh may implement SPIFFE-compatible identities, but deploying a service mesh is not a prerequisite for SPIFFE.

These patterns are most useful when there are enough services or runtime environments that manual credential distribution and rotation are becoming an operational risk. For a small deployment, a simpler platform-managed identity integration may be easier to operate.

Getting Started: Register and Inspect an Identity

Start with one low-risk workload and a test trust domain. Install the SPIRE server and agent using the official deployment guide, configure a node-attestation method for the environment, and confirm that the agent can connect to the server. The exact server and agent configuration depends on the runtime; do not copy a Kubernetes attestation configuration into a VM deployment.

In a Kubernetes SPIRE deployment configured with the k8s_psat node attestor, a registration entry can match a namespace and service account. The example assumes the cluster ID is prod-cluster and the SPIRE server administrative socket is available to the operator:

spire-server entry create \
  -spiffeID spiffe://example.org/ns/payments/sa/api \
  -parentID spiffe://example.org/spire/agent/k8s_psat/prod-cluster \
  -selector k8s:ns:payments \
  -selector k8s:sa:api

Use the actual trust domain, attestation configuration, cluster ID, and administrative socket for your installation. Keep the administrative socket restricted to operators; an application should use the agent’s Workload API socket instead. Deploy a test pod with the matching Kubernetes service account, then inspect the agent and server health:

spire-server healthcheck
spire-agent healthcheck

From a workload container with the SPIRE agent socket mounted at /run/spire/sockets/agent.sock, fetch an X.509 SVID for an initial inspection:

spire-agent api fetch x509 \
  -socketPath /run/spire/sockets/agent.sock

Confirm that the returned SPIFFE ID is the expected spiffe://example.org/ns/payments/sa/api, that the certificate is currently valid, and that a test client validates it against the correct trust bundle. Health checks and an issued certificate are not proof that application authorization is correct. Before production, test denied identities, rotation, agent restarts, trust-bundle updates, and the effect of losing access to the Workload API.

For production adoption, define ownership for registration entries and trust bundles, monitor issuance and renewal failures, and plan how to rotate the trust-domain authority. Test failure behavior as deliberately as the successful path: workloads should not silently fall back to unauthenticated connections or reuse expired credentials when identity issuance becomes unavailable.

Common Misconceptions

• “SPIFFE is a secret manager.” SPIFFE defines workload identities and credential interfaces. It can help a secret manager authenticate a workload, but it does not store or authorize access to every secret.
• “A SPIFFE ID grants access by itself.” An identity is a verifiable name, not an authorization policy. A service must still validate credentials and decide which identities can call which operations.
• “SPIRE and a service mesh are the same thing.” SPIRE implements workload identity and credential delivery. A service mesh adds traffic management and other data-plane functions; either system may integrate with SPIFFE concepts, but they have different responsibilities.
• “Mutual TLS prevents every service attack.” Mutual TLS can authenticate peers and encrypt connections. It does not fix overly broad authorization, vulnerable application code, or compromised workloads.

Related Articles

• Microservices Security: Securing APIs, Services, and Containers
• Istio Service Mesh Implementation
• Zero Trust Security Model
• Identity and Access Management Fundamentals

Changelog

• Initial publication.

Last updated: October 5