Changing the SPIFFE ID of Every SPIRE-Enabled Workload at Uber - Challenges and Lea...
summary
Uber migrates the SPIFFE ID format across a fleet of SPIRE agents on thousands of hosts and million+ identities, creating parallel registrations so workloads temporarily have two SVIDs, forcing a policy-first rollout to avoid breakage. Workarounds include batched registration changes, per-workload whitelists for slow-updating services, and adding an orchestrator field to the SPIFFE ID. Pain points are hard-coded IDs, lack of a preferred-identity mechanism in SPIRE, and agent scalability (including agent OOMs), and the migration succeeds only after careful sequencing and stakeholder coordination.
AI-written summary · about
chapters (10)
- 0:00Intro
- 0:47Agenda
- 1:24Background
- 2:40A SPIRE Registration
- 3:35Problem Statement
- 4:23Approach-2
- 5:55Challenges
- 8:13Migration steps
- 10:32Learnings
- 12:47New SPIFFE ID format
related talks
16mUsing SPIRE in Production at Uber
26m10 Lessons From Migrating to SPIFFE After 10 Years Of Service Identity at Square
36mFederated Identity for Distributed Systems: Understanding SPIFFE
20mSecuring Kafka with SPIFFE at TransferWise
17mFortifying Microservice Security with SPIRE and OPA
26mFortifying gRPC Microservices: Beyond JWT with mTLS and SPIFFE
30mIstio New Workload Identity Provision Pipeline Based on Envoy SDS
40mScaling code health with always on rewrites and AI at Spotify