SPIFFE Workload Identity Integration with Cilium
“Security as code: The best (and maybe only) path to securing cloud applications” Welcome to Zero Trust Data Security!
Reading Time: 3 minutes
Table of Contents
SPIFFE Workload Identity Integration with Cilium
Presentation by Accuknox on “SPIFFE Workload Identity with Cilium” at the Production Identity Day in North America – 2021.
SPIFFE provides a strong identity base flexible for most scenarios. Integrating SPIFFE natively in the Cilium CNI has advantages, since integration does not change any data-path.SPIFFE is now capable of supporting delegation Identity APIs, that allows privileged process to request SVIDs on behalf of the workload, wherein privileged process needs to be on the same node but not in the same pod.
Briefly about Cilium…
eBPF-based Networking, Observability, and Security
Cilium: Identity Aware
- Cilium derives numeric Identity from k8s labels
- Identity is used in eBPF data-plane and can enforce L3/L4 authz on per packet basis
- No use of iptables/netfilter
- Identity is synchronized using a KVStore
Components of Identity?
Our need for SPIFFE
- Consistent Identity across the eco-system not just k8s-workloads
- Ability to federate identity with third party services
- Single Identity across all policy enforcement engines {network, system, data}
- Ability to use TPMs/Enclaves for secure attestation
Integration Challenges
- Cilium deploys Envoy in Node-Singleton Model
- Does not use side-car model
- Advantages, Disadvantages?
Need for SPIRE Delegation APIs
- Implications of Envoy node-singleton model used by Cilium
- SPIRE’s k8s-workload attestation model expects the attestation API to be called
from the same cgroups of the workload - Envoy is no more co-located within the workload pods, thus no access to cgroups
- SPIRE’s k8s-workload attestation model expects the attestation API to be called
- Delegated Identity APIs: Allow a privileged process to fetch SVID on behalf of the
workload process outside of the cgroups
Ensuring appropriate API access
- Guardrails for appropriate access to these delegation APIs?
- Only local node-scope access allowed
- Caller has to be registered with SPIRE-Agent
- Use selectors that can only be attested by privileged process
Use SPIFFE ID for L3/L4 authz
- Creating SPIFFE ID as a k8s label allowed for L3/L4 authz based on SPIFFE ID
- Thus, allows use of classic Cilium Identity model for L3/L4 authz
Upgrading to secure connections
- TLS origination and termination support
Other 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
Summary
- SPIFFE provides a strong identity base flexible for most scenarios
- Integrating SPIFFE natively in the Cilium CNI has advantages
- Integration didn’t change any data-path eBPF handling in Cilium
- SPIFFE now support Delegation Identity APIs
- allowing privileged process to request SVIDs on behalf of the workload
- privileged process needs to be on the same node but not in the same pod
- Cilium next todos
- Using the SPIFFE provisioned certs for IPSec/WireGuard
- Extending for the use JWTs
Credits
- Code contributions from
- @mauriciovasquezbernal (Mauricio)
- @rscampos (Raphael)
- @navarrothiago (Thiago)
- Detailed reviews from
- @jrajahalme (Jarno),
- @joestringer (Joe),
- @evan2645 (Evan),
- @azdagron (Andrew)
- Awesome SPIRE/SPIFFE and Cilium community
References
- PR for Cilium changes [#17335]
- PR for SPIRE-API-SDK changes [#8]
- PR for SPIRE-Agent changes [#2481]
- Design documents
- Cilium-SPIRE-tutorials GH repo
- spiffe.io
- cilium.io
Let us know if you are seeking additional guidance in planning your cloud security program.
- Schedule 1:1 Demo
- Product Tour
On an average Zero Day Attacks cost $3.9M
4+
Marketplace Listings
7+
Regions
33+
Compliance Coverage
37+
Integrations Support