SPIFFE (Secure Production Identity Framework for Everyone) provides a standard for workload identity, while SPIRE (SPIFFE Runtime Environment) is its reference implementation. SPIRE issues SVIDs (SPIFFE Verifiable Identity Documents) as X.509 certificates or JWTs to workloads via a Unix socket on each node. Security weaknesses include: SPIRE agent socket world-readable allowing any local process to obtain any registered workload identity, registration entries with overly broad selectors granting unintended workloads access to privileged identities, trust bundle theft enabling offline SVID forgery, federation configuration errors collapsing trust domain boundaries, and the SPIRE server admin gRPC API accessible without mTLS in default dev configurations. This guide covers systematic SPIFFE/SPIRE security assessment.
# SPIRE agent exposes workload API via Unix socket (default: /tmp/spire-agent/public/api.sock)
# If socket permissions are world-readable, any local process can request SVIDs
# Check SPIRE agent socket permissions
ls -la /tmp/spire-agent/public/api.sock 2>/dev/null
ls -la /run/spire/sockets/agent.sock 2>/dev/null
# srw-rw-rw = world-writable = any process can fetch SVIDs
# Use spire-agent CLI to fetch SVID from socket
spire-agent api fetch x509 \
-socketPath /tmp/spire-agent/public/api.sock 2>/dev/null
# If selectors match any registered entry, returns valid X.509 SVID
# Enumerate all SVIDs available to current process context
spire-agent api fetch x509 \
-socketPath /tmp/spire-agent/public/api.sock \
-write /tmp/stolen-svid 2>/dev/null && \
openssl x509 -in /tmp/stolen-svid/svid.0.pem -noout -text 2>/dev/null | \
grep -E "(Subject:|URI:|Not After)"
# Subject URI contains SPIFFE ID: spiffe://trust-domain/workload-name
# Fetch JWT SVID (useful for API impersonation)
spire-agent api fetch jwt \
-socketPath /tmp/spire-agent/public/api.sock \
-audience api.internal.example.com 2>/dev/null | head -5# SPIRE registration entries define which workloads get which SPIFFE IDs
# Over-broad selectors (e.g., any pod in a namespace) grant unintended identities
# List all registration entries (requires SPIRE server admin access)
spire-server entry show \
-socketPath /tmp/spire-server/private/api.sock 2>/dev/null | \
grep -A5 "Entry ID"
# Via spire-server API — show entries with broad K8s namespace selectors
spire-server entry show \
-socketPath /tmp/spire-server/private/api.sock \
-selector k8s:ns:production 2>/dev/null | head -40
# Entries selecting only by namespace mean ANY pod in that namespace gets the SPIFFE ID
# Test: can we get a privileged SPIFFE ID from a low-privilege pod?
# From inside a pod in 'production' namespace:
spire-agent api fetch x509 \
-socketPath /run/spire/sockets/agent.sock 2>/dev/null | \
grep "spiffe://" | head -5
# If returns high-value identity (e.g., spiffe://example.org/database) from an unprivileged pod,
# the entry selector is over-broad| Security Test | Method | Risk |
|---|---|---|
| Agent socket world-readable | ls -la /tmp/spire-agent/public/api.sock — check permissions | Critical |
| Over-broad entry selector allows SVID theft | Fetch SVID from unprivileged workload matching namespace-only selector | Critical |
| Trust bundle accessible — enables SVID forgery | Read CA cert from agent socket or config path | High |
| SPIRE server admin API without mTLS | spire-server entry show without cert — succeeds | High |
| Federation trust domain collapse | SVID from domain A accepted by domain B services without policy | High |
| Join token reuse for node attestation | Reuse a captured join token to attest a rogue SPIRE agent | High |
Ironimo tests SPIFFE/SPIRE deployments for agent socket over-permissive access, registration entry over-privilege enabling SVID theft, trust bundle exposure, SPIRE server admin API authentication bypass, trust domain federation misconfiguration, attestation plugin weakness, and SVID TTL and rotation policy gaps.
Start free scan