Drawing Lines in the Sand, or Running Unprivileged eBPF in Kubernetes
summary
eBPF often does not need full privileged:true: on modern kernels (>= 5.8) a minimum of CAP_BPF only (kernels >=5.8) plus usually CAP_PERFMON to read perf events runs many probes. Persistent maps force bpffs mounts, which is why people turn on privileged, but a short-lived init-container mounts bpffs then drops privileges for the main pod avoids that. Specific features need specific caps: CAP_NET_RAW to sniff sockets and CAP_NET_ADMIN to attach traffic-control/modify packets.
AI-written summary · about
chapters (12)
- 0:00eBPF introduction
- 1:04What eBPF is and why it matters
- 3:54eBPF use cases in Kubernetes
- 6:25eBPF elevated permissions need
- 7:52BPF filesystem permission challenge
- 10:42BPF init containers solution
- 11:48Minimal eBPF permissions
- 13:33Network monitoring requirements
- 15:00User space library monitoring
- 17:28Cases requiring system admin
- 19:13eBPF permissions takeaways
- 20:37Q&A on unprivileged eBPF
related talks
30mObservability in Kubernetes: Unlocking the Power of eBPF
25mProtecting Modern Workloads with eBPF superpowers
36meBPF for Runtime Security
40mPanel Discussion: eBPF: A New Era in Cloud Infrastructure Tools
32mContainer Escape Paths Nobody Monitors: Abusing Linux Debug Interfaces
47mUsing eBPF to Bring Kubernetes-Aware Security to the Linux Kernel
24mChecking Your --privileged Container
36mPanel: Exploring eBPF Use Cases in Cloud-Native Security