Working Out SPIFFE Identity for Cilium CNI
summary
Cilium integrates SPIFFE/SPIRE by adding a delegated identity API that lets the node-local Cilium agent fetch SVIDs for pods (via a Unix domain socket and SPIRE selectors) and translate those SVIDs into Kubernetes labels then mapped to Cilium numeric identities for eBPF enforcement. This enables the same SPIFFE ID to drive L3/L4 and L7 policies, transparent HTTP→mTLS origination using workload certificates, no added eBPF datapath overhead, and nested SPIRE for tenant isolation; IPsec/WireGuard use is pending.
AI-written summary · about
chapters (12)
- 0:00Intro
- 0:34Briefly about Cilium...
- 2:00Cilium: Identity Aware
- 3:52Components of Identity?
- 6:54Our need for SPIFFE
- 8:14Integration Challenges • Cilium deploys Envoy in Node-Singleton Model Does not use side-car model Advantages, Disadvantages?
- 10:23Ensuring appropriate API access spiff
- 12:41Upgrading to secure connections • TLS origination and termination support
- 13:42Other perks of using SPIFFE • Integrated certificate management solution Integrates well with existing CA providers Nested SPIRE allows hard-isolation of resources • Readily integrates with Vault for secrets management • Active developer community
- 14:37To sum up...
- 15:59Credits
- 16:19References
related talks
36mIntroducing SPIFFE: An Open Standard for Identity in Cloud Native Environments [I]
31mCommunity Integrations and other Works in Progress
30mIntro: SPIFFE
41mSPIFFE Project Intro
37mZero Trust Workload Identity in Kubernetes
36mSPIFFE: In Theory and in Practice
32mProduction Workload Identity with SPIRE
40mMulti-Cloud Workload Identity With SPIFFE