The problem

Service A calls service B. Service B asks: “is this really service A?”

The traditional answers — shared API keys, mTLS with manually-managed certs, IP allowlists — all break in K8s where pods are ephemeral and IPs rotate. SPIFFE replaces all of them with verifiable identity documents (SVIDs) issued at runtime to workloads.

The shape

┌─────────────────┐
│ SPIRE Server    │    issues SVIDs based on attestation policy
│ (control plane) │
└────────┬────────┘
         │
   ┌─────┴─────┐
   │           │
┌──┴──┐    ┌───┴──┐
│Agent│    │Agent │   one per node, attest workloads to the server
└──┬──┘    └──┬───┘
   │          │
┌──┴────┐  ┌──┴───┐
│ pod A │  │ pod B│   each pod gets an SVID via the Workload API
└───────┘  └──────┘

Each pod’s SVID is signed by the SPIRE server. Service B verifies service A’s SVID against the SPIRE server’s public key.

The SVID format

An SVID is an X.509 cert (or a JWT, depending on use case). The Subject Alternative Name is a SPIFFE ID:

spiffe://genie.example/ns/prod/sa/kyc-orchestrator

Structure: spiffe://<trust-domain>/<arbitrary path>. The path encodes namespace, service account, and any other policy-relevant context.

Attestation

The interesting part: how does SPIRE decide whether a pod gets an SVID? Attestation policy. Example policies:

• Pod has Kubernetes service account kyc-orchestrator in namespace prod → issue SVID spiffe://genie.example/ns/prod/sa/kyc-orchestrator
• Process binary SHA matches <known good hash> → issue SVID
• Node is in cloud provider zone asia-south1-a → issue regional SVID

Combine these — “K8s namespace AND binary hash” — for defence-in-depth attestation.

Genie’s plan

pkg/identity ships DID + W3C VC primitives in Go. SPIRE wiring at deploy time is on the roadmap (PCSE §1.2 partial). The shape:

1. SPIRE server in cluster.
2. SPIRE agent DaemonSet on every node.
3. Genie pods include the SPIFFE Workload API socket as a volume.
4. Genie’s gRPC server uses SPIFFE certs for mTLS automatically (the spiffe/go-spiffe library handles cert rotation).

After SPIRE is in, the audit log can carry the calling SVID alongside the user identity — “user alice, calling agent kyc_orchestrator (SVID spiffe://genie.example/ns/prod/sa/kyc-orchestrator), accessed patient record 12345.” Three layers of attribution.

When it pays back

The cost of SPIRE is operational (one more control plane). The benefit:

• No more shared API keys between services.
• mTLS certs rotate automatically (no more “the cert expired at midnight” outages).
• Audit trail includes verifiable service identity (not just self-reported names).
• Federations between separate SPIRE installations let cross-org service-to-service trust work without shared secrets.

For a regulated multi-service deployment, this is the right shape. For a single-service deployment, it’s overkill — JWT and mTLS via cert-manager suffice.

The classic guide: SPIFFE.io documentation, plus the spiffe/go-spiffe library. Two weeks of setup, three years of “we never have to think about service identity again.”