SPIRE (spiffe/spire): SPIFFE IDs and SVIDs for Workload Identity

The problem: workloads need identities that are not secrets you copy around

Most systems that want mutual TLS start by generating a private key, getting it signed, and then distributing that key and certificate to every process that needs it. The distribution step is the weak point. A certificate copied into a container image, a config map or a shared volume is a bearer token, and rotating it means touching every consumer.

SPIRE takes a different position. The README describes it as a toolchain of APIs for establishing trust between software systems across a wide variety of hosting platforms. Instead of you deciding which certificate belongs to which process, an agent running on the node attests the process that is asking, and the server issues it a SPIFFE ID and an SVID. The identity is derived from what the workload demonstrably is (its Kubernetes service account, its Unix UID, its AWS instance identity document), not from a file someone placed there.

That makes SPIRE interesting to platform teams running Kubernetes, to operators with mixed VM and container estates, and to anyone who needs a workload to authenticate to a secret store, a database or a cloud provider without a long-lived credential. The README names exactly those cases.

How the server, agent and Workload API fit together

The architecture has two long-running components and one API surface. SPIRE Server holds the signing authority and the registration entries. SPIRE Agent runs on each node where workloads execute and exposes the SPIFFE Workload API over a Unix domain socket. Workloads do not talk to the server; they talk to the local agent.

The flow is: a workload connects to the Workload API socket, the agent attests that workload using a node attestor and a workload attestor, and if a registration entry matches, the agent returns an SVID and the trust bundle. The README states that this lets two workloads establish trust, for example by establishing an mTLS connection or by signing and verifying a JWT token. It also notes that SPIRE can enable workloads to authenticate to a secret store, a database, or a cloud provider service.

Two design consequences are worth stating plainly. First, the agent is a per-node dependency: if it is not running, workloads on that node cannot obtain or renew SVIDs. Second, the registration entry is the actual authorization decision. Attestation proves what a workload is; the entry decides what identity it receives. Getting that mapping wrong is the most common way to hand out an identity you did not intend.

On the integration side, the README points to official client libraries for the Workload API in Go and Java, and to an implementation of the Envoy Secret Discovery Service, which can install and rotate TLS certificates and trust bundles in Envoy.

Installing SPIRE and getting a first SVID

The README gives three distribution routes. Pre-built releases at the releases page contain both the SPIRE Server and SPIRE Agent binaries. Container images are published for spire-server, spire-agent and oidc-discovery-provider. Building from source is documented in CONTRIBUTING.md.

If you build from the repository, the Makefile's default target is build, which the help text describes as building all SPIRE binaries. The Dockerfile passes a git_tag build argument through to that target, so the Makefile is the supported path rather than a raw go build invocation.

make build

The output lands in bin/, which the Dockerfile walks when it verifies the static binaries. If you prefer containers, the README names the published images and their registry paths, which is the shorter route.

Configuration lives under conf/ in the repository, split into server and agent trees, and the Dockerfile creates directories for both at /opt/spire, /etc/spire/server and /run/spire/server/private. The README does not reproduce a full server or agent config in the text available here; it directs readers to the Quickstart Guides for Kubernetes, Linux and MacOS at spiffe.io/spire/try/ for the first run. Follow those rather than assembling a config from the directory listing, because the plugin blocks are where the details live.

Once an agent is running and a registration entry exists, a workload reads its SVID from the Workload API socket. The README points to the SPIRE tutorials and examples repositories for working code, and to the SPIFFE Library Usage Examples page for the list of official and community libraries.

Where SPIRE is the wrong tool

SPIRE issues SPIFFE IDs, which are URI-shaped identities such as spiffe://trust-domain/path. They are not DNS names, and the trust domain is not a public domain you can get a certificate authority to validate for you. If your requirement is a publicly trusted TLS certificate for a public DNS name, SPIRE is solving a different problem.

The operational weight is the second constraint. You are running a server with a signing authority and a datastore, plus an agent on every node that hosts workloads. That is a control plane, and it needs the same care as any other: backup, upgrade sequencing, and a plan for what happens when the server is unreachable while SVIDs are expiring. The README does not document rollback procedures, and the repository files here do not describe what happens to in-flight SVID rotation during a server outage. Treat that as something to establish from the project's own documentation before you depend on it.

There is also a scope mismatch worth naming. If every workload already runs in one cluster and the cluster's own service account token is enough for the systems you talk to, the attestation layer SPIRE adds is overhead. SPIRE earns its place when identities must be comparable across clusters, clouds or a mix of VMs and containers, which is precisely the wide variety of hosting platforms the README mentions.

SPIRE compared with running cert-manager alone

The closest thing many Kubernetes teams already run is cert-manager, which watches resources and writes issued certificates into Secrets. The difference in approach is the identity model, not the certificate format.

cert-manager answers the question "what certificate should exist for this object?" It reconciles a desired certificate against an issuer and stores the result where the pod can mount it. The pod's claim to that certificate is whatever RBAC allowed it to mount the Secret. SPIRE answers "what is this process, and what identity does that entitle it to?" The workload never holds a stored credential to present; it asks the local agent, which attests it. Renewal is a property of the agent's connection, not a mounted file that must be replaced.

That does not make cert-manager obsolete. For ingress certificates, for certificates bound to DNS names, and for teams that want issuance to be a Kubernetes reconciliation loop, cert-manager is the simpler fit. SPIRE's advantage shows up when the consumer is not a Kubernetes object with a mountable volume, or when the same identity concept has to work on a VM outside the cluster. The README's Envoy SDS implementation is the clearest illustration: certificates and trust bundles are installed and rotated in Envoy transparently, without a Secret in the path.

Upgrades, licence and what maintenance looks like

SPIRE is licensed under Apache-2.0, which permits commercial use and modification and requires that you preserve the licence and notices. That is a permissive licence, and this is not legal advice; check it against your own policy.

The repository shows a conventional Go release cadence. Releases v1.15.1, v1.15.2 and v1.15.3 landed on 2026-05-28, 2026-07-09 and 2026-08-21, and the last push to main was on 2026-09-26. The project is not archived. There is a CHANGELOG.md at the repository root, and RELEASING.md documents the release process, so upgrade notes have a home.

The upgrade cost is not the binary swap. It is the trust bundle and the plugin configuration. Server and agent versions have to be compatible, and the go.mod file shows the breadth of the plugin surface: AWS, Azure, Google Cloud, Keyfactor EJBCA and more are compiled in. A version bump can move those SDK dependencies, which matters if you rely on a cloud attestor or key manager. Read the CHANGELOG for the release you are moving to and check whether your attestation and key manager plugins are affected before rolling agents.

Editorial conclusion

Adopt SPIRE if you run workloads whose identity should follow the process rather than a hostname or a pre-shared secret, and you are willing to run a server, an agent per node and the attestation plugins that match your platform. Do not adopt it if you only need TLS certificates for public DNS names, or if you cannot operate a stateful control plane. Before committing, check the attestation plugins your platform needs in conf/, confirm the datastore choice, and read how upgrades handle the trust bundle in the release notes.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. spiffe/spire on GitHub