Zero-Trust Workload Identity in Kubernetes: SPIFFE, SPIRE, Cilium
Why IP-based network policies fail in Kubernetes, and how SPIFFE, SPIRE, and Cilium enable cryptographic workload identity and enforced mutual TLS.
Pod IPs in Kubernetes are ephemeral — rolling deployments, node drains, and autoscaling can hand a pod's old address to a completely different workload within moments. NetworkPolicies built on IP addresses or label selectors therefore offer a false sense of security, since they verify location rather than identity. What's actually needed is mutual cryptographic verification between services before any data is exchanged — mutual TLS.
SPIFFE, a CNCF standard, and its reference implementation SPIRE address exactly this gap. SPIFFE defines a URI-based identity format (spiffe://) scoped to a trust domain, materialized as an SVID — either X.509 or JWT — that a workload can present. SPIRE Server acts as the central CA, maintaining a registry of which SPIFFE IDs belong to which workloads, while a SPIRE Agent running as a DaemonSet on every node performs node attestation and exposes the Workload API over a Unix socket so workloads can request their identities.
Cilium leverages this SPIRE infrastructure through eBPF to enforce mTLS without injecting a sidecar into every pod. A CiliumNetworkPolicy can require that traffic between two services only flows when a valid, SPIRE-signed certificate is presented — if the certificate doesn't match, the connection is refused regardless of the source IP.
For engineers, this closes a real gap: security posture no longer silently erodes as pods are rescheduled or scaled, because policy enforcement is now tied to cryptographic identity instead of network location. It's a zero-trust layer that complements existing RBAC and certificate practices without requiring any changes to application code.