eBPF: how it works and why it matters for cloud native security

Executive overview

Traditional security tools track IP addresses — useless in Kubernetes environments where containers spin up and die constantly. eBPF (Extended Berkeley Packet Filter) hooks programs directly into the Linux kernel to observe syscalls, processes, and network events in real time, without modifying the kernel itself.

It enables security tools to track containers by process rather than IP, create observation-based allow-list policies, and respond to threats at kernel speed.

The core insight: eBPF makes the Linux kernel programmable the same way JavaScript makes HTML programmable — without replacing it.

What eBPF is

• Extends the original Berkeley Packet Filter beyond network filtering to cover observability, networking, and security
• Lets you attach programs to kernel events (syscalls, sockets, network cards, virtual filesystem) without writing or waiting for kernel modules
• Adding kernel modules the traditional way takes 1–2 years via the Linux community review process; eBPF bypasses that entirely
• Programs are written in a constrained subset of C, or more commonly via pre-built libraries (BCC, Cilium, etc.)
• Three broad use-case umbrellas: system observability, networking, security

How it functions

• Compile: eBPF code (restricted C) is compiled to bytecode; most teams now pull pre-compiled bytecode from libraries rather than writing their own
• Verify: a kernel verifier checks for infinite loops, unsafe memory operations, and code size limits before anything touches the kernel
• JIT compile: bytecode is compiled a second time into architecture-native instructions (e.g. x86) for performance comparable to native kernel code
• Attach: programs hook onto kernel locations via kprobes (kernel space), uprobes (user space), or predefined tracepoints
• Execute: on each trigger, the eBPF program reads the event and either writes to a map (key-value store bridging kernel and user space) or acts immediately
• The map acts as a state-translation layer — user-space applications read from it and write back to it for bidirectional coordination

Why it matters for cloud native security

• Cloud native workloads use ephemeral containers with constantly changing IP addresses — IP-based monitoring breaks down
• Traditional tools also lack visibility into Linux namespaces, which are fundamental to container isolation
• eBPF tracks containers by process ID rather than IP, providing stable identity across the container lifecycle
• Gives visibility into Kubernetes pod labels, namespaces, kernel internals, and network metadata simultaneously
• Enables real-time policy enforcement at kernel level, not just after-the-fact alerting

Security use cases

• Cryptojacking detection: sidecars only see their own pod; an eBPF program at the kernel level sees all pods on the node, including attacker-spun pods running Monero miners
• Observation-based allow-list policies: spin up a fresh container, observe its syscall behaviour, bake that into a YAML policy (e.g. Cilium Tetragon) — privileged pod creation gets blocked automatically
• Terminal command tracking: every command typed in a terminal is a syscall; eBPF can log or block commands associated with known malware patterns
• DDoS mitigation (XDP): attaching an eBPF program to a network card via XDP (Express Data Path) allows packet drops before they reach the kernel stack — Cloudflare benchmarked ~10 million packets dropped per second, far ahead of traditional methods
• Advanced malware sandboxing: eBPF intercepts syscalls used by malware to detect sandboxes (RAM size, CPU count, sleep duration) and returns fake values, preventing evasion

Malicious use cases (offensive research)

• Data illusion: an eBPF program intercepts file-read syscalls for a specific PID and returns fabricated data, making two users on the same host see different file contents
• Invisible root: a malicious eBPF program grants a specific user instant root (sudo) access without a password by intercepting and approving the syscall silently
• Self-concealment: a malicious eBPF program can intercept calls to introspection tools (e.g. bpftool) and hide itself from the list of running programs