SPIRE

Sign in to the Azure portal, open Create a resource, and search the Marketplace for SPIRE by SecureAnyCloud. Select the SecureAnyCloud listing and choose Create.

On the Basics tab, pick your subscription and resource group, a region, and a VM size of Standard_B2s or larger. Under Administrator account, select SSH public key, set the username to azureuser, and supply your public key. Under Inbound port rules, allow SSH (22) only.

Complete the Networking tab with your virtual network and subnet, then select Review + create and Create.

First boot initialisation generates this VM's own trust domain and certificate authority and registers the demonstration workload. It takes a short moment after the VM state becomes Running.

Choosing your own trust domain

To choose the trust domain name yourself rather than letting the VM derive one, write a single line containing it to /etc/sac/spire-trust-domain before first boot. For example, use cloud-init user data:

#cloud-config write_files: - path: /etc/sac/spire-trust-domain content: | example.org

If you do not supply one, the VM derives a unique trust domain from its hostname, so two SecureAnyCloud VMs never share a trust domain by accident.

The following block launches a VM from the SecureAnyCloud SPIRE image into an existing resource group. Replace the values in angle brackets with your own. The image reference comes from the Marketplace listing's Usage information.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:spire-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-resource-group> \
  --name spire \
  --image sac1647283583153:spire-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard

When the VM reaches the Running state, note its public IP address from the portal or with az vm list-ip-addresses.

Connect over SSH as azureuser using your key pair.

ssh azureuser@<vm-ip>

Check that both halves of SPIRE are installed and running.

spire-server --version spire-agent --version sudo systemctl is-active spire-server.service spire-agent.service

The output looks like this:

1.15.2 1.15.2 active active

Both the server and the agent expose plain HTTP health endpoints on the loopback address. They are the quickest way to confirm that the identity system is up.

curl -fsS http://127.0.0.1:8080/ready echo
curl -fsS http://127.0.0.1:8082/ready echo

The output looks like this:

{"catalog.datastore":{},"server":{},"server.ca":{},"server.ca.rotator":{}} {"agent":{}}

Confirm that SPIRE listens on the loopback address only. The server's node API on 8081 is deliberately not reachable from outside the VM in the shipped image.

sudo ss -tln | grep -E ':(8080|8081|8082) '

The output looks like this:

LISTEN 0 4096 127.0.0.1:8080 0.0.0.0:* LISTEN 0 4096 127.0.0.1:8081 0.0.0.0:* LISTEN 0 4096 127.0.0.1:8082 0.0.0.0:*

First boot writes a root-only summary of this VM's identity configuration. It records your trust domain, the identity paths in use and the fingerprint of your certificate authority. It contains no private key material.

sudo cat /root/spire-credentials.txt

The file records values like these. Your trust domain and fingerprint are unique to your VM.

spire.trust.domain=<your-vm>.spire.sac.internal spire.agent.id=spiffe://<your-vm>.spire.sac.internal/agent/sac-local spire.workload.demo.id=spiffe://<your-vm>.spire.sac.internal/workload/demo spire.workload.demo.user=spire-workload spire.ca.fingerprint.sha256=CC:55:70:68:24:2A:50:EF:... spire.server.socket=/run/spire/server/private/api.sock spire.agent.socket=/run/spire/agent/public/api.sock spire.server.bind=127.0.0.1:8081

The single-use join token that bootstrapped the local agent was generated on this VM, consumed immediately, and deleted. It is not recorded in this file.

A running process and an open socket prove nothing about an identity system. The image ships a self test that proves the whole path end to end. It is the fastest way to confirm that your deployment works.

The self test pulls the trust bundle directly from the server. It has the demonstration workload fetch an SVID over the Workload API into a fresh directory, and checks that the SVID carries your trust domain. It verifies the certificate chain against the server-supplied bundle and confirms that an unrelated certificate authority is rejected. Finally, it reconfirms the positive case.

sudo /usr/local/sbin/spire-identity-roundtrip.sh

The output looks like this:

OK trust_domain=<your-vm>.spire.sac.internal workload=spiffe://<your-vm>.spire.sac.internal/workload/demo ca_sha256=CC:55:70:68:24:2A:50:EF:...

Any other output begins with FAIL and names the step that did not hold.

The server tracks which agents have attested and which workloads may receive which identities.

sudo spire-server agent list -socketPath /run/spire/server/private/api.sock

The output looks like this:

Found 1 attested agent: SPIFFE ID : spiffe://<your-vm>.spire.sac.internal/spire/agent/join_token/fc29a008-8ea7-4bcd-b417-a1904a16b416 Attestation type : join_token Expiration time : 2026-07-19 17:03:13 +0000 UTC Serial number : 167376281661483824124114967622690597522 Can re-attest : false Agent version : 1.15.2

Now list the registration entries.

sudo spire-server entry show -socketPath /run/spire/server/private/api.sock

Two entries exist on a fresh VM. The first is the delegated agent identity, .../agent/sac-local, which is the parent your own workload entries hang off. The second is the demonstration workload, selected by the unix user id it runs as.

Entry ID : 9641806b-147c-490c-8fc6-ad1d259dfef8 SPIFFE ID : spiffe://<your-vm>.spire.sac.internal/workload/demo Parent ID : spiffe://<your-vm>.spire.sac.internal/agent/sac-local Revision : 0 X509-SVID TTL : default JWT-SVID TTL : default Selector : unix:uid:997

Fetch an identity document as the demonstration workload and inspect what SPIRE issued. The workload identity is granted on the basis of the unix user the process runs as, so run the fetch with sudo -u spire-workload.

The SPIFFE identity is carried in the certificate's URI Subject Alternative Name, which makes it verifiable by any SPIFFE-aware peer.

WD=$(mktemp -d); chmod 777 "$WD"
sudo -u spire-workload spire-agent api fetch x509 \
  -socketPath /run/spire/agent/public/api.sock -write "$WD/" openssl x509 -in "$WD/svid.0.pem" -noout -text | grep -A1 "Subject Alternative Name" openssl x509 -in "$WD/svid.0.pem" -noout -issuer -dates openssl verify -CAfile "$WD/bundle.0.pem" "$WD/svid.0.pem" rm -rf "$WD"

The output looks like this:

Received 1 svid after 1.839615ms SPIFFE ID: spiffe://<your-vm>.spire.sac.internal/workload/demo SVID Valid After: 2026-07-19 16:04:08 +0000 UTC SVID Valid Until: 2026-07-19 17:04:18 +0000 UTC CA #1 Valid After: 2026-07-19 16:03:02 +0000 UTC CA #1 Valid Until: 2026-07-26 16:03:12 +0000 UTC Writing SVID #0 to file /tmp/tmp.uj6oEt8zMe/svid.0.pem. Writing key #0 to file /tmp/tmp.uj6oEt8zMe/svid.0.key. Writing bundle #0 to file /tmp/tmp.uj6oEt8zMe/bundle.0.pem. X509v3 Subject Alternative Name: URI:spiffe://<your-vm>.spire.sac.internal/workload/demo issuer=C = GB, O = sac, CN = sac SPIRE CA (<your-vm>.spire.sac.internal), serialNumber = 97931985402370782961606615520983568838 notBefore=Jul 19 16:04:08 2026 GMT notAfter=Jul 19 17:04:18 2026 GMT /tmp/tmp.uj6oEt8zMe/svid.0.pem: OK

Note the one-hour lifetime. Short-lived identities are the point of SPIFFE. The agent renews them automatically well before expiry, so there is no long-lived credential to steal or rotate by hand.

Register one of your own services by selecting on the unix user id it runs as. The trust domain is read from the credentials file, so you can copy the command as is.

The block is safe to rerun. SPIRE rejects a duplicate registration with AlreadyExists, so the block checks for the entry before creating it.

TD=$(sudo grep '^spire.trust.domain=' /root/spire-credentials.txt | cut -d= -f2-) SOCK=/run/spire/server/private/api.sock MYID="spiffe://${TD}/workload/my-service"
EXISTING=$(sudo spire-server entry show -socketPath "$SOCK" -spiffeID "$MYID" 2>/dev/null || true) case "$EXISTING" in *"Entry ID"*) echo "Entry already exists for $MYID" printf '%s\n' "$EXISTING" ;; *)
sudo spire-server entry create -socketPath "$SOCK" \
  -parentID "spiffe://${TD}/agent/sac-local" \
  -spiffeID "$MYID" \
  -selector "unix:uid:$(id -u www-data)" ;; esac

The output looks like this:

Entry ID : 3f9d1a0e-e37e-4192-862b-36822ee9675f SPIFFE ID : spiffe://<your-vm>.spire.sac.internal/workload/my-service Parent ID : spiffe://<your-vm>.spire.sac.internal/agent/sac-local Revision : 0 X509-SVID TTL : default JWT-SVID TTL : default Selector : unix:uid:33

Any process running as that user can now fetch its identity from the Workload API socket, with no secret to distribute.

Selectors are not limited to the unix user id. unix:gid, unix:path and other selectors let you describe a workload as precisely as you need.

The trust domain certificate authority signing keys, the registration datastore and the agent's own node identity all live on a dedicated Azure data disk mounted at /var/lib/spire. The disk is separate from the operating system disk, so you can resize and snapshot it independently.

df -h /var/lib/spire
sudo ls -l /var/lib/spire/server /var/lib/spire/agent

The output looks like this:

Filesystem Size Used Avail Use% Mounted on /dev/sdc 16G 304K 15G 1% /var/lib/spire /var/lib/spire/agent: -rw------- 1 root root 2944 Jul 19 16:04 agent-data.json -rw-r--r-- 1 root root 1062 Jul 19 16:03 bootstrap-bundle.crt -rw------- 1 root root 222 Jul 19 16:03 keys.json /var/lib/spire/server: -rw-r----- 1 spire spire 143360 Jul 19 16:03 datastore.sqlite3 -rw------- 1 spire spire 425 Jul 19 16:03 keys.json

server/keys.json holds your trust domain's certificate authority signing keys. It is readable only by the spire service user, and it was generated on this VM. Back up this disk if you need your trust domain to survive the VM.

The shipped image runs a single-node identity system. The server listens on 127.0.0.1:8081 only, so no unauthenticated identity API is exposed to the network. To attest SPIRE agents running on other hosts, bind the server to a routable address and open the port to those hosts only.

Edit /etc/spire/server/server.conf and change bind_address from 127.0.0.1 to 0.0.0.0. Then restart the server:

server { bind_address = "0.0.0.0" bind_port = "8081" ... }

Then allow inbound 8081 from the hosts that need it, never from the whole internet:

az network nsg rule create \
  --resource-group <your-resource-group> \
  --nsg-name <your-nsg> \
  --name allow-spire-server \
  --priority 1010 \
  --protocol Tcp --destination-port-ranges 8081 \
  --source-address-prefixes <your-workload-cidr> \
  --access Allow

Each remote agent needs its own join token, generated on the server, plus a copy of your trust bundle:

TD=$(sudo grep '^spire.trust.domain=' /root/spire-credentials.txt | cut -d= -f2-) sudo spire-server token generate \
  -socketPath /run/spire/server/private/api.sock \
  -spiffeID "spiffe://${TD}/agent/remote-host-1" -ttl 600
sudo spire-server bundle show -socketPath /run/spire/server/private/api.sock

Join tokens are single-use and short-lived. For production fleets, consider a node attestor suited to your platform rather than issuing tokens by hand.

The Azure managed identity node attestors require Azure identity configuration that you set up yourself. They are deliberately not enabled in this image, so that it works standalone out of the box.