OSS TanbouSign in with GitHub

attest running workloads and issue short-lived SVID credentials bound to SPIFFE identities

About these scores

OSS scale score is an unbounded metric that log-compresses and weights Stars, Watchers, Forks, and Contributors. Discovery score is the current OSS scale score minus the score at discovery. Update pace is commits in the last 30 days, growth momentum is the OSS scale score difference within the recent observation window, and OSS health is a 0–100 rating based on available recency, Community Health, and release data.

Stars
2,569
Primary language
Go
License
Apache-2.0
Repository last updated
Oct 2, 2026
On this page

Overview

SPIRE is a workload identity system whose servers and agents attest running software and issue SPIFFE IDs and SVIDs. Applications can use its X.509 certificates or JWTs for mutual TLS, token verification, and authentication to other services.

Features and best fit

Based on official documentation; not hands-on tested · Content checked:

Key features

Derive an identity and short-lived credentials from the runtime environment

SPIRE Server manages a trust domain and registration entries while SPIRE Agents attest processes on their nodes. A matching workload obtains a SPIFFE ID and automatically rotated, short-lived SVIDs through the Workload API without embedding credentials in application configuration.

Sources: [1][3]

Use the same identity for mTLS, JWTs, and Envoy integration

X.509-SVIDs support mutually authenticated TLS and JWT-SVIDs support token-based authentication. The project also documents an Envoy Secret Discovery Service integration and maintained Go and Java client libraries.

Sources: [1]

Best fit

Fits dynamic services that need one identity model across environments

SPIRE fits services spread across Kubernetes, virtual machines, and physical hosts when identity should follow an attested workload rather than a copied certificate or static API key. It is especially useful when credential issuance and rotation should be removed from individual applications.

Sources: [1][3]

Before adoption

Treat the localhost join-token configuration as an evaluation setup

The bundled sample binds to 127.0.0.1 and uses join_token attestation, SQLite, an in-memory key manager, and the example.org trust domain. Production requires deliberate node and workload attestation, durable key and datastore choices, trust-domain boundaries, and availability planning.

Sources: [4][5][9]

SPIRE does not replace every secret-management or authorization component

Its central responsibility is workload attestation and identity issuance. Teams still need to define how secret storage, human identity, authorization policy, and service-mesh behavior divide responsibility with SPIRE.

Sources: [1][10]

Official sources

  1. [1]SPIRE v1.15.3 README(2026-10-04)
  2. [2]SPIRE v1.15.3 release(2026-10-04)
  3. [3]SPIRE architecture overview(2026-10-04)
  4. [4]SPIRE v1.15.3 localhost server configuration(2026-10-04)
  5. [5]SPIRE v1.15.3 localhost agent configuration(2026-10-04)
  6. [6]SPIRE v1.15.3 Go toolchain requirement(2026-10-04)
  7. [7]SPIRE v1.15.3 server healthcheck implementation(2026-10-04)
  8. [8]SPIRE v1.15.3 agent healthcheck implementation(2026-10-04)
  9. [9]SPIRE v1.15.3 scaling and deployment guide(2026-10-04)
  10. [10]SPIRE comparison with adjacent systems(2026-10-04)
Supplemental curator note

SPIRE is worth evaluating when a team wants to replace credentials distributed to every service with SPIFFE identities and short-lived SVID credentials derived from the runtime environment. Keep the localhost join-token demo separate from production design for trust domains, node attestation, durable storage, and availability.

Try it in 3 steps

  1. 1

    Clone v1.15.3 into a private area and build

    Provide Go 1.26.6 or later, make, Python 3, and GNU timeout (gtimeout from coreutils on macOS), then build the fixed tag in a unique private temporary area.

    umask 077 && spire_demo_dir=$(mktemp -d "${TMPDIR:-/tmp}/spire-demo.XXXXXX") && cd "$spire_demo_dir" && git clone --branch v1.15.3 --depth 1 https://github.com/spiffe/spire.git && cd spire && go_version=$(go env GOVERSION) && awk -v v="${go_version#go}" 'BEGIN{split(v,a,".");exit !((a[1]>1)||(a[1]==1&&a[2]>26)||(a[1]==1&&a[2]==26&&a[3]>=6))}' && timeout_bin=$(command -v timeout || command -v gtimeout) && test -n "$timeout_bin" && make bin/spire-server bin/spire-agent
  2. 2

    Prepare an isolated localhost configuration

    Create evaluation configs with unique data directories, sockets, and a free localhost port, without shared PID or token files.

    spire_port=$(python3 -c 'import socket;s=socket.socket();s.bind(("127.0.0.1",0));print(s.getsockname()[1]);s.close()') && run_dir="$spire_demo_dir/run" && server_conf="$spire_demo_dir/server.conf" && agent_conf="$spire_demo_dir/agent.conf" && mkdir -p "$run_dir" "$spire_demo_dir/server-data" "$spire_demo_dir/agent-data" && cp conf/server/server.conf "$server_conf" && cp conf/agent/agent.conf "$agent_conf" && sed -i.bak -e "s#bind_port = \"8081\"#bind_port = \"$spire_port\"#" -e "s#/tmp/spire-server/private/api.sock#$run_dir/server.sock#" -e "s#data_dir = \"./.data\"#data_dir = \"$spire_demo_dir/server-data\"#" "$server_conf" && sed -i.bak -e "s#server_port = \"8081\"#server_port = \"$spire_port\"#" -e "s#/tmp/spire-agent/public/api.sock#$run_dir/agent.sock#" -e "s#data_dir = \"./.data\"#data_dir = \"$spire_demo_dir/agent-data\"#" "$agent_conf"
  3. 3

    Fetch an SVID and always reap the owned processes

    Start both processes inside one subshell, bound each request with GNU timeout, and fetch an X.509-SVID. On success or failure, cleanup kills and waits only for the owned PIDs, while the caller's trap remains intact.

    ( set -e; s= a=; cleanup(){ for p in "$a" "$s"; do test -z "$p" || kill "$p" 2>/dev/null || true; done; for p in "$a" "$s"; do test -z "$p" || wait "$p" 2>/dev/null || true; done; }; ready(){ for i in 1 2 3 4 5 6 7 8 9 10; do "$timeout_bin" 2s "$@" >/dev/null 2>&1 && return; sleep 1; done; return 1; }; trap cleanup EXIT INT TERM; ./bin/spire-server run -config "$server_conf" >"$spire_demo_dir/server.log" 2>&1 & s=$!; ready ./bin/spire-server healthcheck -socketPath "$run_dir/server.sock"; token=$("$timeout_bin" 5s ./bin/spire-server token generate -socketPath "$run_dir/server.sock" -spiffeID spiffe://example.org/myagent | awk '/Token:/{print $2}'); test -n "$token"; ./bin/spire-agent run -config "$agent_conf" -joinToken "$token" >"$spire_demo_dir/agent.log" 2>&1 & a=$!; ready ./bin/spire-agent healthcheck -socketPath "$run_dir/agent.sock"; "$timeout_bin" 5s ./bin/spire-server entry create -socketPath "$run_dir/server.sock" -parentID spiffe://example.org/myagent -spiffeID spiffe://example.org/demo -selector "unix:uid:$(id -u)"; "$timeout_bin" 10s ./bin/spire-agent api fetch x509 -socketPath "$run_dir/agent.sock" )
Check the official README

Growth

Growth trends · Last 30 days

2,569 Stars

Trend data is still being collected.

Development activity

Last 90 days · weekly

Commits (last 30 days)
37
Open PRs
25

Development activity is still being collected.

Built with

Categories and tags

GitHub data

GitHub dataView detailed GitHub data
Stars
2,569
Forks
671
Watchers
79
Open issues
92
Contributors
289
Owner type
Organization
Primary language
Go
License
Apache-2.0
Repository last updated
Oct 2, 2026
Write a related article

Share a guide or use case for this OSS in Markdown. Articles are published after administrator approval.

Report incorrect information

Tell us if any listing information is incorrect or outdated.

After reading this page, do you know what to do next?