Cilium Service Mesh Speaker: Thomas Graf CTO & Co-Founder Isovalent, Cilium Maintainer, Chair GB eBPF Foundation

Makes the Linux kernel programmable in a secure and efficient way. “What JavaScript is to the browser, eBPF is to the Linux Kernel” Process Scheduler execve() Linux Kernel Syscall

- Networking - Security - Observability - Service Mesh & Ingress -based: Foundation Created by Technology

Security Observability & Runtime Enforcement

Cilium Service Mesh Istio - Istio manages sidecars - Cilium enforces L7 NetworkPolicy in Istio sidecars - Cilium accelerates the sidecar network injection path - Cilium manages combination of eBPF + per-Node proxy - No sidecars - Can support any control plane Option 2: Istio Integration Option 1: Sidecar-free eBPF Mesh

😨 Cleartext TLS Encrypted Example of Istio + Cilium Collaboration ⚠ Anybody with CAP_NET_ADMIN can ready everything in clear text.

✅ No unencrypted payload on any network interfaces Istio Example of Istio + Cilium Collaboration

Service Mesh

Traditional networking is falling short tcpdump, NetFlow, sFlow, … SSH, IPsec, Wireguard, VPN, .. L4 Load-Balancing (IPVS, iptables, …) TCP retransmissions We need L4 (TCP, UDP) -> L7 (HTTP, gRPC, …) Network

Service Mesh Origins

Service Mesh with Sidecars

Complex Injection Many, many Sidecars Sidecar Complexity

Cilium Service Mesh - Sidecar-free Datapath - Use eBPF when possible, fallback to Envoy - Native performance & latency - mTLS support for any network traffic (UDP, SCTP, Multicast, …) - Envoy CRD - Bring the control plane of your choice: Istio SMI Ingress / Services Gateway API SPIFFE - Observability integrations (Hubble + Tetragon) More information: https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh Linkerd(?)

Service Mesh Evolution

What about multi-tenancy? We made the kernel aware of namespaces and cgroups to enable multi-tenancy. We call it containers.

Integrating Envoy into the Kernel Stack - Envoy threads can run in cgroup of pod - No sidecar injection needed - No network injection needed - No need to stop Envoy - No need to start Envoy at pod startup Granularity of proxy: - Node - Namespace - ….

Reduced Footprint

Traffic Management - L3/L4 forwarding & Load-balancing - Canary, Topology Aware Routing - Multi-cluster Security - Network Policy - mTLS Observability - Tracing, OpenTelemetry, & Metrics - HTTP, TLS, DNS, TCP, UDP, … eBPF Native (no sidecar) Proxy Traffic Management - L7 Load-balancing & Ingress Resilience - Retries, L7 Rate Limiting Security - TLS Termination & Origination When eBPF cannot do it Whenever possible

mTLS with Cilium Service Mesh - Works for any protocol (UDP, SCTP, …) - Avoids once allowed connections to be allowed forever - Keeps secrets out of proxy (Useful when proxy runs untrusted user filters) More information: https://isovalent.com/blog/post/2022-05-03-servicemesh-security

No Visibility Sidecar HTTP Visibility (P95) HTTP Authorization No Proxy Cilium Envoy Filter Istio Envoy Filter In-kernel HTTP parser Some benchmarks* - All in-kernel with - Istio concurrency & resource constraints removed - 1x per node proxy vs 2x sidecars - Cilium Envoy filter less complex All data & Scripts: https://isovalent.com/blog/post/2022-05-03-servicemesh-security

Cilium Envoy Filter Istio Envoy Filter Default Resource & Concurrency Contraints Bonus benchmark Make sure to review the default concurrency and resource constraints!

Thank you!