As your services scale inside an organization, this trust model crumbles: “this IP is ours, so trust it.” IPs change, NAT layers appear, a mesh shows up, pods are reborn — and you keep on writing ACLs. The modern stance is to anchor trust to the workload’s identity instead.
SPIFFE standardizes that identity, and SPIRE makes it real with automated certificate issuance and rotation.
1) Goal: answer the question “who is calling?”
In SPIFFE-land, an identity looks like this:
spiffe://example.org/ns/payments/sa/api
Properties:
- It belongs to the workload, not an IP
- The certificate is short-lived (minutes/hours)
- Rotation must be automated
2) Minimum components
A typical Kubernetes setup:
- SPIRE Server: CA / identity authority + registration entries
- SPIRE Agent: runs on each node and hands SVIDs to workloads
- Workload attestation: pod/SA/namespace selectors that say “this workload gets this identity”
3) Setup skeleton (Kubernetes)
The steps below are a “reference skeleton”; adapt them to your own deployment standard.
3.1 Picking a trust domain
- Choose a single trust domain for the org:
spiffe://corp.example - If you need environment separation, consider sub-domains or separate servers (the prod/stage split must be obvious).
3.2 SPIRE Server/Agent installation
The install flow varies (Helm/manifest). The critical pieces:
- Durable storage for server state (persist)
- Run the Agent safely on the node (privileged may be required; minimize it)
- Bootstrap trust between Server and Agent (node attestation)
3.3 Workload registration entry
The logic: “if these selectors match, hand out this SPIFFE ID.”
Sample approach:
- Namespace:
payments - ServiceAccount:
api - SPIFFE ID:
spiffe://corp.example/ns/payments/sa/api
4) Application integration: 2 practical paths
4.1 mTLS via sidecar/proxy (the most pragmatic option)
A proxy such as Envoy fetches the SVID from the SPIRE Agent and enforces outbound/inbound mTLS.
Upside:
- Minimal changes to application code
Downside:
- If the proxy doesn’t actually verify identity, mTLS turns into encryption-only.
4.2 mTLS inside the application (controlled but expensive)
The application itself fetches the SVID and feeds it into its TLS stack.
Upside:
- Full control
Downside:
- Language/SDK fragmentation and ongoing maintenance cost
5) Operations: rotation, revocation, observability
A minimum operational checklist:
- SVID TTL: short but realistic (e.g. 1 hour)
- Rotation: zero-downtime (renewal window)
- Logs: reasons for mTLS handshake failures (SAN, SPIFFE ID, expiry)
- Metrics: certs issued, failed attestations, agent connection errors
- Audit: who got which identity via which selector?
6) Common mistake: defining the identity “too loose”
If you keep selectors loose:
- The wrong workload picks up the wrong identity
- Lateral movement gets easier
- Post-incident forensics becomes harder
My recommendation: keep selectors tight at the start (namespace + serviceAccount). Loosen them only as needs emerge.
7) Final word
Workload identity built on SPIFFE/SPIRE is more than “certificate automation”: it gives the organization a real service identity and trust model. In a world where IPs shift and infrastructure is fluid, the only stable thing left is identity. So move trust onto identity, automate rotation, and design for observability from day one.