SPIFFE and SPIRE: workload identity for cloud-native environments

A container that lives for 30 seconds needs a verifiable identity to call another service. It cannot have a static credential hardcoded. It may not have time to request one from a human-operated vault. Its IP address changes every time it is scheduled. Traditional identity mechanisms — service accounts, API keys, IP-based trust — were designed for long-lived, statically located workloads.

SPIFFE (Secure Production Identity Framework for Everyone) defines a standard for workload identity using cryptographically-verifiable SVIDs (SPIFFE Verifiable Identity Documents) that bind identity to workloads without requiring network perimeter trust (Source: spiffe.io). SPIRE (the SPIFFE Runtime Environment) is the CNCF reference implementation of the SPIFFE standard, providing node and workload attestation to issue SVIDs to workloads based on verified platform properties (Source: spiffe.io).

SPIFFE is the standard — it defines SVIDs, trust domains, the SPIFFE ID format, and the Workload API. It does not specify how attestation works. SPIRE is the reference implementation — it provides node agents, server infrastructure, attestation plugins, and the concrete mechanism by which SVIDs are issued. An organization can implement SPIFFE without SPIRE, though SPIRE provides the most complete attestation framework for production use. (Source: SPIFFE)

Why SPIFFE and SPIRE matter

Workload identity without SPIFFE creates three operational risks: credential sprawl, identity lifecycle drift, and service mesh complexity. Container environments spawn hundreds of ephemeral services that need to authenticate to databases, APIs, and each other. Each requires an identity that proves its legitimacy without static credentials.

Without SPIFFE, practitioners hardcode service account tokens in container images, inject secrets via environment variables, or rely on IP-based firewall rules for service authentication. These approaches fail when workloads move between nodes, scale dynamically, or operate across multiple clusters.

It is worth noting that cloud-native alternatives address some of these problems within a single platform. EKS Pod Identity, IRSA, GKE Workload Identity, and Azure Workload Identity all provide short-lived, automatically rotated credentials for workloads running on their respective platforms. Kubernetes service account tokens are also now short-lived and audience-bound by default. SPIFFE and SPIRE become the stronger choice when workloads span multiple platforms or clouds, when identity needs to federate across organizational boundaries, or when a consistent attestation model across heterogeneous infrastructure is required.

SPIFFE provides cryptographic identity that survives workload rescheduling. (Source: SPIRE Use Cases - SPIFFE) Organizations reduce hardcoded secrets and gain more granular service-to-service authentication policies, though they accept the operational complexity of attestation infrastructure and certificate lifecycle management.

Service mesh deployments gain mTLS automation when SPIRE acts as the certificate authority. Instead of managing static certificates or relying on mesh-generated CAs, workloads receive time-bound X.509 certificates that automatically rotate based on attestation policies.

Core capabilities

Identity format and trust domains

A SPIFFE ID is a URI in the format spiffe://<trust-domain>/<path> that uniquely identifies a workload within a trust domain and is encoded in an X.509 certificate (X509-SVID) or JWT token (JWT-SVID) (Source: spiffe.io). The trust domain establishes the authority boundary — workloads within the same trust domain share a root of trust, while cross-domain authentication requires federation.

The path component identifies the specific workload based on platform properties. In Kubernetes, a workload SPIFFE ID might look like spiffe://production.example.com/ns/payments/sa/processor for a workload in the payments namespace using the processor service account. Note that node or agent identities follow a different format: spiffe://<trust-domain>/spire/agent/<attestor>/<...> — for example, spiffe://production.example.com/spire/agent/aws_iid/123456789012/us-east-1/i-1234567890abcdef0. Keeping workload and agent identities conceptually distinct matters when designing registration entries and policies.

Attestation framework

SPIRE performs two-stage attestation: node attestation followed by workload attestation. Node attestation verifies the node before trusting workload attestation requests from it. Workload attestation verifies the workload and issues the SVID.

Node attestation uses platform-specific plugins. On Kubernetes, the standard attestor is k8s_psat, which uses projected service account tokens validated through the Kubernetes TokenReview API. On AWS, the attestor uses the EC2 Instance Identity Document. On bare metal, TPM-based attestation is available. The SPIRE server validates these platform credentials before establishing trust with the node agent.

Workload attestation happens on the node. The SPIRE agent examines workload properties by querying the local kubelet — Kubernetes pod metadata, process attributes, or container labels — against configured selectors, and issues SVIDs to matching workloads via the Workload API. The server is not involved in workload attestation; it is the agent that performs this verification locally.

An important security property of node attestation: by default, SPIRE only permits a node to attest once. This means a stolen Instance Identity Document cannot be reused to register a second agent, which limits the impact of IID theft.

Workload API integration

The Workload API provides a Unix domain socket interface that workloads use to retrieve their SVIDs and trust bundles. Applications call the API to get their current identity certificate and the root certificates needed to validate other workloads' identities.

The Workload API is streaming. When an SVID approaches expiration, the API pushes an updated certificate to connected clients without requiring an application restart. SDKs such as go-spiffe and java-spiffe handle this rotation automatically, so applications using them do not need to implement their own polling. Many teams avoid application code changes entirely by using Envoy SDS or spiffe-helper, which consume the Workload API on behalf of the application.

Implementation considerations

Platform-specific attestation setup

Kubernetes deployments use the k8s_psat node attestor. The SPIRE server needs access to the Kubernetes TokenReview API to validate projected service account tokens presented by node agents during attestation. The server also needs permission to read pod and node metadata to support registration and selector resolution. Workload attestation does not go through the server — the agent queries the local kubelet for pod metadata and matches it against selectors. Node agents run as DaemonSets with hostPath mounts to expose the Unix domain socket where workloads expect the Workload API.

AWS implementations use the Instance Identity Document for node attestation. The SPIRE server validates the cryptographic signature on the IID against AWS's public key. Configure the AWS attestor plugin with the expected AWS account ID to scope attestation to your environment and prevent cross-account issues. As noted above, SPIRE's single-use attestation by default means a stolen IID cannot be replayed to register an additional agent. (Source: spiffe.io)

GCP uses instance metadata for node attestation. The SPIRE server validates the instance identity token against Google's OIDC endpoint. The service account used by the SPIRE server requires only read access to instance metadata, and only when instance metadata selectors are in use. Do not grant roles/compute.instanceAdmin — that provides write access far beyond what attestation requires.

Protecting the SPIRE server's signing keys

The SPIRE server holds the signing keys for your trust domain. Any party that obtains these keys can mint arbitrary SVIDs for any workload identity in the domain. This makes the SPIRE server a high-value target that warrants corresponding controls: use a KMS-backed key manager or an upstream CA rather than file-based keys, apply strict access controls to the server deployment, and treat the SPIRE server infrastructure as a crown jewel system in your threat model.

Node compromise and registration scoping

A compromised node can obtain SVIDs for every workload registration entry mapped to it. This means registration scoping and selector specificity directly affect blast radius. Using broad selectors — for example, matching on Kubernetes namespace alone — allows any pod in that namespace to claim the registered identity. Use the most specific combination of selectors that is practical: namespace plus service account, or namespace plus pod label, rather than namespace alone. Consider what a compromised node could impersonate when designing your registration entries.

Registration automation

At any meaningful scale in Kubernetes, managing registration entries by hand is not practical. The SPIRE Controller Manager automates entry creation by watching Kubernetes resources and reconciling them against SPIRE registration entries. Factor this into your deployment architecture early rather than treating manual registration as a temporary starting point.

Trust domain design

Design trust domains around administrative boundaries, not application boundaries. (Source: Scaling SPIRE - SPIFFE) A single trust domain per environment (development, staging, production) often works better than per-application domains because it simplifies cross-service authentication within the environment.

Federation enables authentication across trust domains. SPIRE servers exchange trust bundles through the federation API, allowing workloads in different domains to validate each other's SVIDs. Use federation for cross-cluster authentication or when organizational boundaries require separate trust domains.

SVID configuration

Set SVID TTL based on your rotation tolerance and security requirements. (Source: github.com) SPIRE's defaults are 1 hour for X509-SVIDs and 5 minutes for JWT-SVIDs. Shorter TTLs reduce credential exposure windows but increase API load. Multi-day TTLs undercut the core value of short-lived identity — a compromised credential valid for days provides an attacker a long window to operate. Keep X509-SVID TTLs in the range of minutes to a few hours for production workloads.

X509-SVIDs work with standard TLS libraries and service mesh implementations and are the recommended default. JWT-SVIDs integrate with HTTP Bearer authentication and OIDC-compatible services, but carry an important caveat: they are bearer tokens that can be replayed if intercepted. Always restrict JWT-SVIDs to a specific audience, and prefer X509-SVIDs where the transport and library support it.

OIDC discovery provider

One of the most common practical reasons teams adopt SPIRE is the OIDC Discovery Provider. It exposes a standards-compliant OIDC endpoint backed by SPIRE's trust domain, allowing workloads to exchange JWT-SVIDs for AWS, GCP, or Azure credentials without any static keys or cloud-provider-specific SDK integration. This enables cloud API access for workloads running outside those clouds — or across multiple clouds — using a single identity system.

Service mesh integration

Istio's built-in CA already issues SPIFFE-format SVIDs, so workloads in an Istio mesh have SPIFFE-compatible identities by default. Integrating SPIRE as an external identity source extends this with stronger, platform-verified attestation and the ability to federate identity across clusters and non-mesh workloads. When SPIRE integration is configured, Envoy sidecars connect to the SPIRE agent's Workload API socket via SDS — typically mounted using the SPIFFE CSI driver — to retrieve certificates rather than obtaining them from Istio's built-in CA. This is the mechanism that makes cross-platform identity consistent.

Linkerd runs its own identity service and issues certificates to proxies through that component. Linkerd does not consume certificates from the SPIRE Workload API in the manner described by some guides. If SPIRE-backed identity in Linkerd is a requirement, consult current Linkerd documentation for the supported integration path before proceeding.

Choose SPIRE integration when you need consistent workload identity across multiple service mesh implementations or when federating identity with external systems. (Source: spiffe.io) Use native mesh CAs when identity stays within a single mesh deployment and cross-platform federation is not required.

Getting started checklist

Pre-implementation assessment

SPIRE server configuration

Agent deployment

Application integration

Sources