Every way of watching a Linux system used to hurt. Write a kernel module and a single bug panics the whole machine — and you get to recompile it for every kernel update. Trace a process with ptrace, the interface behind strace, and the traced process pays a CPU penalty so severe the exercise turns unusable in production. Or poll /proc for snapshots: cheap, and blind to everything that happens between polls, including the short-lived processes attackers love.
Look at the three failures separately and a pattern shows up. The module fails on safety and upkeep: native code with full access, one bug away from taking down the machine, rebuilt for every kernel version it has to run on. ptrace fails on cost: the observation itself slows the observed process so badly that production — the place you most need visibility — is exactly where you can't afford it. Polling fails on time: snapshots show the system at intervals, and an attacker who lives between the intervals is effectively invisible. Safety, cost, time. What the industry needed was a fourth option that didn't charge any of the three.
Containers and Kubernetes finished off all three options. Ephemeral workloads, kernels that vary from node to node, agents that must be both safe and cheap — the industry needed a way to run custom logic inside the kernel without the risk of custom kernel code. It got one. It's called eBPF, and heavyweight agents have been giving way to lightweight in-kernel probes ever since.
Checked before it runs
The technology has a modest ancestor. The classic Berkeley Packet Filter was a tiny language for filtering network packets, nothing more. In 2014, kernel developer Alexei Starovoitov rewrote it into something else entirely: a general-purpose in-kernel virtual machine with 11 64-bit registers.
The key move is what happens before a program ever runs. The kernel's eBPF verifier checks each program and proves it will terminate, cannot crash the kernel, and cannot access memory out of bounds. Only after that proof does the just-in-time compiler translate the bytecode into native machine code. Userspace programs can then attach logic to hundreds of hook points — system calls, tracepoints, network interfaces, socket operations — without recompiling the kernel or loading a module.
Contrast that with the trust model it replaced. A kernel module is believed because someone loaded it; once inside, it has full access and the kernel takes its behavior on faith. An eBPF program is believed because it was checked. Termination is proven, not hoped for, so a probe can't hang the machine in a loop. Memory access is bounded, so a probe can't wander into data it has no business reading. And because the JIT compiles the verified bytecode into native machine code, the safety doesn't come at the price of an interpreter's overhead.
Portability took longer. CO-RE — Compile Once, Run Everywhere — solved it, enabled by BTF (BPF Type Format) metadata embedded in modern kernels. A program compiled against one kernel version runs on different kernels without recompilation, ending the version-chasing that plagued earlier tooling. The eBPF Foundation, hosted by the Linux Foundation, now stewards the ecosystem. CO-RE mattered because the cloud-native world is heterogeneous by default: kernels vary from node to node in the same cluster, and a tool compiled for one machine's kernel and broken on the next is a tool a platform team can't roll out.
Cilium ate the network first
Networking came first. The most visible eBPF success story is Cilium, the CNCF-graduated project that reimplemented Kubernetes networking. Traditional Kubernetes networking leans on iptables, where packet-filtering rules are evaluated as a linear chain — as services and pods multiply, evaluation slows in proportion. Cilium replaced kube-proxy's O(N) iptables rules with O(1) eBPF map lookups, processing packets directly in the kernel data path.
But the speed isn't the whole story. eBPF brought capabilities iptables never had: network policy enforced at Layer 7, so rules can understand HTTP and gRPC rather than just IP addresses, and transparent encryption between pods. Cilium's companion, Hubble, builds on the same programs to deliver flow-level observability — every TCP connection, every DNS query, every HTTP request across the cluster — with Kubernetes context attached: which pod, which namespace. No application changes.
The context point is worth lingering on. A packet on its own is an event; a packet attached to a pod, a namespace and a service is evidence. When something goes wrong in a cluster — a connection that shouldn't exist, a DNS query to somewhere strange — the first question is never just what happened but whose it is. Hubble's flow records answer both at once, from the same programs that move and police the traffic. Network teams and security teams usually buy those two views from two different vendors and reconcile them by hand. Running both off one kernel substrate removes the reconciliation, and removes the second agent that used to do the watching.
Detection turned into enforcement
Security was the natural next frontier. Falco, the CNCF's de facto standard for runtime threat detection, uses eBPF to observe every system call in every container and matches behavior against rules: an unexpected shell spawning in a production container, a process writing to a sensitive file, a privilege escalation attempt. Because the hooks live in the kernel, detection happens in effectively real time.
Tetragon, also from the Cilium project, pushes further — into enforcement. Traditional host intrusion detection reads audit logs in userspace, which gives an attacker time to finish an operation before anyone notices. Tetragon's eBPF programs can kill a process or drop a network packet at the kernel layer the moment malicious behavior is detected. Policies are expressed as Kubernetes-native custom resources, so the same GitOps workflows that manage deployments manage security policy, with full awareness of which pod, namespace and service account is acting.
The difference between the two models is a difference in tense. Log-based detection is past tense: the operation happened, the record traveled to userspace, and a response begins after the fact. Falco's rules narrowed that gap — watching every system call in every container means the shell spawning where no shell belongs gets flagged as it happens, not in tonight's log review. Tetragon closes the gap entirely by acting in the kernel at the moment of detection: the process dies or the packet drops before the operation completes. An attacker racing a log pipeline usually wins. An attacker racing the kernel layer itself is racing something that runs before the malicious call finishes.
That same instinct — move protection as close to the machine as it will go — is why teams pair kernel visibility with a second layer inside the process. Runtime application self-protection blocks the memory exploit the probe just watched arrive, and the adversary justifying both investments is patient and well-resourced: nation-state espionage built on harvest-now, decrypt-later collection assumes defenders will miss something, and prices its operations accordingly.
One sensor layer, and its price
Observability followed. Pixie, an open-source Kubernetes observability tool, deploys as a DaemonSet and automatically captures HTTP requests, database queries and DNS resolutions across all services. Developers instrument nothing. Parca and Pyroscope provide continuous, always-on CPU profiling for Go, Python, Java, Ruby and native languages via eBPF, replacing language-specific profilers. And bpftrace offers a high-level tracing language for ad-hoc investigation — a one-liner can stream every file opened system-wide, in real time, with zero application changes.
"Instrument nothing" is the phrase to hold onto. Traditional observability is a tax paid per application: add the library, wrap the calls, redeploy, and accept that the services nobody got around to instrumenting are the ones that will fail blind. An eBPF-based tool inverts the deal. The sensor sits in the kernel, underneath every application equally, so coverage is a property of the node rather than a property of each team's diligence. And when an engineer needs an answer nobody anticipated, bpftrace is the escape hatch — a one-liner, run once, streaming every file opened on the machine in real time. No ticket to add instrumentation. No redeploy. The question gets asked at the speed of the incident.
Step back and the migration looks like a quiet consolidation. The old model stacked agents on every node: a networking daemon managing iptables, a host intrusion detection system tailing audit logs, an APM agent injected into each application, a profiling daemon sampling CPU. Each consumed its own memory and CPU. Each needed its own upgrade cycle. Each saw only its slice of the machine. The eBPF model collapses the stack. A single privileged DaemonSet loads the kernel programs, and the kernel itself becomes the sensor, the policy engine and the enforcement point. Networking policy, runtime threat detection, flow logging and profiling all draw from the same hook points. When a new kernel ships, CO-RE means the programs keep working without a rebuild. When a new workload deploys, it inherits full visibility automatically — no agent to install, no SDK to integrate, no sidecar to inject. The clearest expression is the service mesh: the traditional model ran a full Envoy proxy as a sidecar in every pod, multiplying memory usage with every replica, while the eBPF-backed ambient model moves traffic interception to the node layer. Mesh capabilities, no per-pod proxies.
The power has a sharp edge. Loading programs into the kernel requires the CAP_BPF or CAP_SYS_ADMIN capability, which is why the default container seccomp profile blocks the bpf() system call — and why granting a workload eBPF privileges is a deliberate trust decision, not a default. A compromised eBPF loader could install malicious probes. The verifier guarantees safety against crashes. It does not guarantee anything about the intent of an authorized loader. Mature deployments handle it the way they handle any privileged capability: loaders run as tightly scoped DaemonSets, images are signed and pinned, and loading is restricted to platform-owned namespaces. eBPF loaders get the same scrutiny as any host-level agent, because that is what they are.
The teams doing this consolidation are, more often than not, the same ones carrying the decade's other big rebuilds: refitting HSM fleets for the FIPS 203 post-quantum deadlines, and planning the wider migration those timelines now demand. Different layers, same direction. Less machinery bolted on, more capability built in — verified before it runs. And the same telemetry discipline shows up at the endpoint, where EDR telemetry catches intruders in the moments before detonation.
Sources
- Dev.to — "eBPF in 2026: The Kernel Revolution Powering Cloud-Native Security and Observability"
- Medium — "What Is eBPF? A Plain-English Guide for Linux, Kubernetes, and Security Engineers" (April 2026)
- Java Code Geeks — "eBPF: Kernel-Level Observability Superpowers for Linux"
- GitHub (mnachmi/k8s-deep-dive) — "Chapter 07: eBPF" (verifier, JIT, Cilium, Tetragon internals)
- DevCrypted — "eBPF Unleashed: Future of Cloud-Native Observability" (Falco, Tracee, bpftrace)
