Integrate SPIRE — Overview
What is SPIRE?
SPIRE (SPIFFE Runtime Environment) is the production-ready implementation of the SPIFFE (Secure Production Identity Framework For Everyone) standard. It automatically issues and rotates cryptographic identities — called SVIDs (SPIFFE Verifiable Identity Documents) — to your workloads based on their runtime attributes.
With SPIRE deployed, every workload (AI agent, microservice, batch job) gets a unique, verifiable identity without managing certificates manually or storing long-lived secrets.
Why Workload Identity Matters
Traditional service authentication relies on shared secrets, API keys, or static certificates — credentials that can be stolen, misused, or forgotten to rotate. SPIRE replaces this model with attestation-based identity:
| Traditional Approach | SPIRE Approach |
|---|---|
| Static secrets stored in config | Short-lived certificates, automatically rotated |
| Identity is a shared credential | Identity is cryptographically bound to the workload |
| Hard to revoke if compromised | Certificates expire in hours; no manual cleanup |
| No proof of what is calling | Selectors verify runtime attributes (namespace, image, UID) |
Key Concepts
SVID (SPIFFE Verifiable Identity Document)
A short-lived X.509 certificate or JWT that proves a workload's identity. Contains the workload's SPIFFE ID (e.g. spiffe://tenant-uuid/agent/.../order-service).
SPIFFE ID
A URI that uniquely identifies a workload within a trust domain. Format: spiffe://<trust-domain>/<path>.
Attestation The process the SPIRE Agent uses to verify a workload's identity before issuing an SVID. It checks runtime attributes — Kubernetes service account, Docker labels, Unix process UID — against registered selectors.
Workload Entry A record in AuthSec that maps a SPIFFE ID to a set of selectors. When a workload's runtime attributes match all selectors, it receives an SVID.
mTLS (Mutual TLS) Both the client and server present their SVIDs during the TLS handshake, so each side cryptographically verifies the other's identity. No API keys required.
JWT-SVID A JWT containing the workload's SPIFFE ID and claims. Used for authorization when passing identity in HTTP headers between services.
Architecture
┌─────────────────────────────────────────────────────────────┐
│ Your Infrastructure (K8s / Docker / VM) │
│ │
│ ┌──────────────┐ Unix Socket ┌──────────────────────┐ │
│ │ Your App │◄──────────────►│ Spire Agent │ │
│ │ + SDK │ gRPC Workload │ (1 per node/host) │ │
│ └──────────────┘ API └──────────┬───────────┘ │
│ │ │
└──────────────────────────────────────────────┼──────────────┘
│ HTTPS (outbound only)
▼
┌──────────────────┐
│ Spire Server │
│ AuthSec Cloud │
└──────────────────┘
- One SPIRE Agent per node/host — runs as a DaemonSet (K8s), sidecar container (Docker), or systemd service (VM)
- Your app never contacts the Spire Server directly — it talks to the local agent over a Unix socket
- All server communication is outbound HTTPS — no inbound firewall rules needed
Certificate Lifecycle
Agent attests → SVID issued → Auto-renewed at 66% TTL → Old cert replaced atomically
The SDK handles renewal transparently. Your application never needs to restart for certificate rotation.
When You Need This
Deploy the SPIRE Agent when your AI agents or services need to:
- Authenticate to each other over mTLS without sharing secrets
- Receive a delegated token from AuthSec (SPIFFE identity is required)
- Prove their identity to downstream services in a zero-trust architecture
- Operate across mixed environments (Kubernetes + VMs + Docker) with a unified identity model
Next Steps
- Getting Started — Requirements and network prerequisites
- Deploy the Spire Agent — Install on Kubernetes, Docker, or a VM
- Register Workload Entries — Onboard your services as clients
- Integrate the SDK — Add SPIFFE identity to your workload code
- Reference — SDK API, certificate rotation, and selector reference