mTLS & SPIFFE/SPIRE Workload Identity

Overview

Overview mTLS (mutual TLS) extends standard TLS so both the client and server present and validate certificates. It provides cryptographic service-to-service identity — neither side can be impersonated without the corresponding private key.

mTLS handshake additions vs TLS: 1. Server sends CertificateRequest after its own Certificate message. 2. Client responds with its certificate and a CertificateVerify (signature over the handshake transcript using its private key). 3. Server validates the client certificate against its trusted CA.

SPIFFE (Secure Production Identity Framework for Everyone): a CNCF standard that defines workload identity. A SPIFFE ID is a URI: spiffe://trust-domain/path (e.g., spiffe://example.com/ns/payments/sa/billing-service). The X.509 certificate encoding a SPIFFE ID is called an SVID (SPIFFE Verifiable Identity Document).

SPIRE (SPIFFE Runtime Environment): the reference implementation. The SPIRE Server is the CA; SPIRE Agents run on each node and attest workloads (by UID, binary hash, Kubernetes service account, or cloud metadata). On attestation, the agent issues a short-lived SVID (typically 1 hour). SVIDs are automatically rotated before expiry.

Istio integration: Istio's control plane (istiod) is a SPIFFE-compatible CA. It issues SVIDs to each Envoy sidecar. PeerAuthentication policy enforces mTLS: STRICT (reject plaintext), PERMISSIVE (allow both — for migration). Authorization policy uses SPIFFE IDs for allow/deny decisions at L7.

Certificate pinning: pins a specific certificate or public key instead of trusting any cert from a CA. More brittle but eliminates CA compromise risk. Used for critical internal APIs.

Key concepts

SPIFFE ID

A URI workload identity: spiffe://trust-domain/path. Encoded in the X.509 SAN (Subject Alternative Name) field. Uniquely identifies a workload regardless of IP address or hostname.

SVID

SPIFFE Verifiable Identity Document. An X.509 certificate or JWT encoding a SPIFFE ID. Issued by SPIRE and typically valid for 1 hour with automatic rotation.

SPIRE Agent

Runs on each node. Attests workloads via selectors (UID, binary checksum, K8s service account, AWS instance identity). Issues SVIDs to attested workloads via the Workload API.

PeerAuthentication

Istio policy that controls mTLS mode per namespace or workload. STRICT rejects plaintext; PERMISSIVE accepts both (for brownfield migration). Applied via Kubernetes CRD.

Short-lived certificates

SVIDs valid for 1 hour (vs traditional certs valid for 1 year). Compromise of a short-lived cert is bounded in time. Eliminates the need for CRL/OCSP revocation infrastructure.

When to use it

• Designing zero-trust service-to-service authentication in microservices
• Explaining why Istio/Linkerd use short-lived certs instead of long-lived API keys
• Debugging mTLS handshake failures (wrong trust domain, expired SVIDs)
• Comparing SPIFFE vs traditional PKI for dynamic cloud workloads

Interview questions

• How does SPIFFE/SPIRE provide workload identity without secrets or API keys?
• What is the difference between Istio PERMISSIVE and STRICT mTLS mode, and when do you use each?

More Networking topics

• IPv6 Addressing & Dual Stack
• Kubernetes Network Policies
• L4 vs L7 Load Balancing
• Latency Diagnosis
• Load Balancing Algorithms
• MPLS
• MTU & IP Fragmentation
• NAT & PAT
• Network Chaos Engineering
• Network Debugging Toolkit
• Network Observability & Flow Analysis
• nginx and HAProxy Configuration