SPIFFE: Cryptographic Identity for Services
SPIFFE gives every service a cryptographic passport instead of a static secret. It's used in zero-trust networks for services to authenticate each other, like in a Kubernetes service mesh.
WHY IT EXISTS: In dynamic environments like Kubernetes, services need to securely identify themselves to other services. Hardcoding secrets, API keys, or long-lived certificates is brittle, insecure, and an operational nightmare. We need a way to automatically issue and rotate verifiable identities for software itself, regardless of where it runs.
THE MENTAL MODEL: SPIFFE provides a universal identity system for services, like a passport office for your code. Instead of a service having a static password, it has a cryptographic "passport" called a SPIFFE Verifiable Identity Document (SVID). This SVID proves the service's identity to others. The SPIFFE framework defines the standards for these passports, and its implementation, SPIRE, is the agent that issues and validates them.
HOW IT WORKS: A SPIRE Server acts as the root authority for a "trust domain." It maintains a registry of which workloads are allowed which identities. SPIRE Agents run on each node (e.g., as a Kubernetes DaemonSet). The agent attests the identity of a workload running on its node based on platform-specific selectors (like a Kubernetes service account). If the workload is verified, the agent issues it an SVID via a local Workload API. The SVID can be an X.509 certificate or a JWT, which the workload then uses to authenticate to other services, often for mTLS.
WHEN TO USE IT: Use SPIFFE for service-to-service authentication in a microservices architecture, especially within a service mesh using proxies like Envoy. It's ideal for implementing zero-trust principles where no service is trusted by default. It excels in dynamic, multi-platform environments (Kubernetes, VMs, bare metal) where you need a consistent identity plane.
WHEN NOT TO USE IT: SPIFFE is not for human authentication; it's designed for machine-to-machine identity. It also introduces operational overhead. For very simple, static applications with only two or three services, managing a few API keys might be simpler than deploying and maintaining a full SPIRE infrastructure. It is overkill for monoliths that don't communicate with other services over the network.
ONE CANONICAL EXAMPLE: In Kubernetes, you deploy a SPIRE Server as a StatefulSet and SPIRE Agents as a DaemonSet. You register a "payments-api" workload, telling the SPIRE Server that any pod with the payments-api service account is allowed the identity spiffe://my.domain/payments-api. When a payments pod starts, the SPIRE Agent on its node verifies its attributes, gets an SVID from the server, and provides it to the pod. The payments-api can now present this SVID to a database service to establish a secure mTLS connection.
Read the original → spiffe.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.