SPIRE on Ubuntu 24.04 LTS

SPIRE is the SPIFFE Runtime Environment, the graduated Cloud Native Computing Foundation project that gives every workload a cryptographically verifiable identity. Instead of distributing shared secrets, API keys or long lived certificates to your services, SPIRE attests what each workload actually is and issues it a short lived identity document, called an SVID, that other services can verify. This image delivers a complete, self contained SPIFFE identity system, with both the SPIRE server and a local SPIRE agent installed and running as hardened system services, so workloads are receiving verifiable identities within minutes of launch.

The SPIRE server is the certificate authority for your trust domain. It attests nodes, holds the registration entries that describe which workloads may receive which identities, and signs the identity documents those workloads receive. The SPIRE agent runs alongside your workloads, proves its own identity to the server, and then serves the SPIFFE Workload API over a local unix socket. Workloads simply ask that socket for their identity and receive a freshly signed certificate and the trust bundle needed to verify their peers, with no secret to store, distribute or rotate by hand.

On its first boot every instance generates its own trust domain and its own brand new certificate authority, with signing keys created locally on that machine. No certificate authority material is shared between instances and none ships in the image, so identities issued on your instance are valid only inside your own trust domain. You can choose the trust domain name yourself before first boot, or let the instance derive a unique one automatically.

A demonstration workload identity and registration entry are created on first boot, together with a self test that proves the whole path end to end. The self test has a real workload fetch an identity document over the Workload API and verifies the certificate chain against the trust bundle taken independently from the server, so you can confirm the system genuinely issues verifiable identities rather than merely that a service is running.

The identity system is closed by default. The server listens on loopback only and its registration interface is a restricted local socket, so no unauthenticated identity API is ever exposed to the network. Node attestation uses a single use join token that is generated on the instance, consumed immediately and then deleted. The trust domain configuration, the certificate authority signing keys and the registration datastore all live on a dedicated data disk kept separate from the operating system disk.

Connect over SSH and the identity system is already running. Read the welcome notes for your trust domain and identity paths, run the self test to see a real identity issued and verified, then register your own services by selecting on the user they run as. Extend outward when ready by opening the server port to attest agents on other hosts.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.