eBPF will help solve service mesh by getting rid of sidecars

Re:eBPF will help solve service mesh by getting rid of sidecars by davewritescode on Thursday December 09, 2021 @11:59AM (#29499843)

From a resource perspective this makes sense but from a security perspective this drives me a little bit crazy. Sidecars aren't just for managing traffic, they're also a good way to automate managing the security context of the pod itself.

The current security model in Istio delivers a pod specific SPIFFE cert to only that pod and pod identity is conveyed via that certificate.

That feels like a whole bunch of eggs in 1 basket.

[ Parent | on HN ]

Re:eBPF will help solve service mesh by getting rid of sidecars by tgraf on Thursday December 09, 2021 @12:07PM (#29499985)

What the proposed architecture allows is to continue using SPIFFE or another certificate management solution to generate and distribute the certificates but use either a per-node proxy or an eBPF implementation to enforce it. Even if the authentication handshake remains in a proxy but data encryption moves to the kernel then that is a massive benefit from an overhead perspective. This already exists and is called kTLS.

[ Parent | on HN ]