eBPF for Kubernetes security
eBPF (extended Berkeley Packet Filter) runs small, verified programs inside the Linux kernel, attached to syscalls, network paths, tracepoints, or kprobes, with low performance overhead. For Kubernetes security, eBPF is the current foundation for runtime threat detection, network policy enforcement, and observability. It has largely replaced sidecar-per-pod architectures because it offers deeper visibility (kernel level) with less footprint (one agent per node instead of per pod).
Why eBPF matters for Kubernetes
- Kernel-level visibility. Every syscall, every socket, every process exec is visible without modifying the workload.
- Per-node, not per-pod. One DaemonSet observes every pod on the node. No sidecar tax.
- Verified safety. The eBPF verifier rejects programs that could crash the kernel. Safer than kernel modules.
- Low overhead. Filtering happens in the kernel. Most uninteresting events never leave kernel space.
What eBPF can do that sidecars cannot
- See every syscall, not just what an instrumented SDK chose to log.
- Observe cross-container activity on the same node without needing CNI plugin changes.
- Enforce network policy in the kernel (Cilium's flagship use case).
- Correlate process tree, network tuple, and file access for a single event.
- Attach to kernel functions that are invisible to userspace.
eBPF projects worth knowing
- Cilium. eBPF-based CNI. Network policy, load balancing, service mesh.
- Falco. Runtime threat detection. Pluggable with eBPF or kmod drivers.
- Tetragon. Runtime detection and enforcement (block or kill). From Isovalent (now Cisco).
- Pixie. Auto-instrumented observability. Now part of New Relic.
- Juliet's runtime sensor. Embedded eBPF-based detection, part of Pro and Enterprise tiers.
Things to know before deploying eBPF
- Kernel version matters. Most current eBPF features require Linux 5.4 or newer. Some need 5.10+. Older managed Kubernetes distributions (EKS on Amazon Linux 2, for example) can limit what is available.
- Privileged DaemonSet. Attaching eBPF requires
SYS_ADMIN, or the newerBPFplusPERFMONcapabilities. Application workloads remain unprivileged. - Debuggability. eBPF program bugs can still drop events or misclassify. Plan for a fallback and test carefully.
- Read how we built Juliet's runtime sensor for a detailed walkthrough of namespace scoping, event pipelines, and the mistakes we made along the way.
Frequently asked about ebpf for kubernetes security
Is eBPF Linux-only?
Primarily. There is Windows eBPF via Microsoft's ebpf-for-windows project, but it is early. For Kubernetes on Linux nodes, which covers almost all production clusters, Linux eBPF is the relevant stack.
Do I need to write eBPF to use it?
No. Packaged tools (Falco, Tetragon, Cilium, Juliet) cover common use cases. Writing raw eBPF programs is advanced and rarely needed outside specialized teams.
Can eBPF kill a process?
Yes. With recent kernels, eBPF programs can send signals (bpf_send_signal) to target processes. Tetragon and Juliet runtime enforcement use this to block attacker behavior in-kernel.
Does eBPF require disabling SELinux or AppArmor?
No. eBPF coexists with MAC systems. Loading eBPF programs requires specific capabilities, which SELinux or AppArmor policies need to permit on the runtime agent's container.
What is the overhead of eBPF-based runtime security?
Typically single-digit percent CPU on nodes with moderate syscall volume. Extreme workloads (high-frequency packet processing without kernel offload) can be higher. The verifier and JIT compiler minimize cost in the common case.
See this in your clusters
Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.