Module 6: SPIFFE & SPIRE Deep Dive

Learning Objectives

• Understand SPIFFE specification and SPIRE architecture
• Deploy SPIRE on Kubernetes with auto-registration
• Configure workload attestation and SVID issuance
• Implement SPIFFE federation across trust domains

Why This Matters

Workload identity is the foundation of cloud-native zero trust. Without it, services cannot prove who they are, mTLS is impossible to manage at scale, and authorization policies have nothing to anchor on. This module gives you the identity layer everything else depends on.

Lesson Content

This module teaches the SPIFFE specification and its production implementation SPIRE. If you have already taken our dedicated Mastering SPIFFE & SPIRE course, this module serves as a recap within the broader cloud-native security context.

SPIFFE in 5 Minutes

SPIFFE (Secure Production Identity Framework For Everyone) defines a standard for workload identity. SPIRE (SPIFFE Runtime Environment) implements it. Together they give every service a cryptographic identity — automatically issued, automatically rotated, cryptographically verifiable.

Key Concepts

• Trust Domain: The root of trust (e.g., spiffe://company.org)
• SPIFFE ID: URI identifying a workload (spiffe://company.org/ns/prod/sa/api)
• X.509-SVID: Certificate proving identity — used for mTLS
• JWT-SVID: Token proving identity — used for HTTP APIs
• Workload API: Unix socket where pods request their identity

SPIRE on Kubernetes

SPIRE Server runs as a StatefulSet. SPIRE Agent runs as a DaemonSet on every node. The Controller Manager auto-registers workloads. The CSI Driver mounts the Workload API socket into pods. The result: every pod gets a cryptographic identity with zero manual configuration.

Why SPIFFE Matters for This Course

SPIFFE is the identity layer that enables everything in subsequent modules: Envoy mTLS (Module 7), OPA authorization (Module 8), Vault integration (Module 9), and production federation (Module 14). Without workload identity, none of these integrations work.

Real-World Use Cases

• Automatic workload identity for 500+ microservices
• Cross-cluster identity with SPIFFE federation
• Replacing shared secrets with SVID-based authentication
• Kubernetes + VM hybrid identity

Common Mistakes

• Using SQLite for SPIRE Server in production (no HA)
• Not monitoring SVID rotation — stalled rotation = imminent certificate expiry
• Overly broad ClusterSPIFFEID selectors matching unintended workloads
• Confusing SPIFFE (identity) with authorization (what identity can do)

Production Story

A fintech company replaced 200+ shared API keys with SPIFFE SVIDs over 3 months. Each service got unique, auto-rotating cryptographic identity. Secret sprawl dropped to zero and the security team could finally audit who accessed what.

Career Relevance

SPIFFE/SPIRE expertise is rare and increasingly demanded. Bloomberg, Uber, and Pinterest use it at scale — and they need engineers who understand it.

Key Terms

SPIFFE

Secure Production Identity Framework For Everyone — the standard

SPIRE

SPIFFE Runtime Environment — the implementation

SVID

SPIFFE Verifiable Identity Document — certificate or JWT

Trust Domain

Root of trust identified by domain name

Attestation

Process of verifying node or workload identity

Hands-On Labs

1. Deploy SPIRE on Kubernetes

   Deploy the complete SPIRE stack on a Kind cluster.

   40 min - Intermediate

   • Create a Kind cluster
   • Deploy SPIRE Server, Agent, and Controller Manager
   • Register a workload and verify SVID issuance
   • Inspect the SVID with openssl

   View lab files on GitHub

2. Configure SPIFFE Federation

   Federate two SPIRE deployments for cross-cluster trust.

   45 min - Advanced

   • Deploy SPIRE on two separate Kind clusters
   • Exchange trust bundles
   • Register federated workloads
   • Verify cross-cluster mTLS communication

   View lab files on GitHub

Key Takeaways

• SPIFFE is the specification, SPIRE is the implementation
• Every pod gets automatic cryptographic identity via SVID
• SPIRE Server (StatefulSet) + Agent (DaemonSet) + Controller Manager = automatic workload identity
• Federation enables cross-cluster and cross-cloud trust
• SPIFFE is the identity foundation for all subsequent security modules