From Adoption to Innovation: LinkedIn’s SPIRE Journey
summary
LinkedIn runs SPIRE to issue X.509 identities for hundreds of thousands of hosts and workloads, deploying regional SPIRE clusters that support 50k nodes per cluster and use TPM-based node attestation with a recorded-device EK registration workflow (TPM EK registration) to bind hardware to trust. The SPIRE servers keep CA material in HSM/TPM-backed memory but use in-memory signing for performance; an agentless GP service handles short-lived certs and GitHub OIDC, reducing first-fetch latency from ~30–60s to much lower.
AI-written summary · about
chapters (11)
- 0:00SPIRE journey at LinkedIn
- 1:27Why SPIRE over SPIFFY
- 3:13SPIRE advantages for LinkedIn
- 4:17Trust model setup
- 5:41SPIRE deployment architecture
- 7:24TPM-based node attestation
- 13:34Identity issuance workflow
- 16:26Agent-based architecture challenges
- 17:29Agentless for non-Linux workloads
- 19:36Lessons from adoption
- 21:23Q&A
related talks
34mScaling SPIRE for Performance and Availability
04mSecurely Bridging Cloud-Native and Traditional Workloads...
33mSPIFFE and SPIRE: Architecture Deep Dive
16mUsing SPIRE in Production at Uber
34mSecuring Multi-Cloud Cross-Cluster Communication with SPIFFE and SPIRE
30mIntro: SPIFFE
26mSPIFFE at GitHub
33mUniform Workload Identity Everywhere: SPIRE Integrations and Extensibility
