Everything you do before deployment — scanning images, signing them, enforcing Pod Security Standards — reduces the odds of a compromise, but none of it tells you when a running container starts behaving like it has been breached. A container that passed every scan can still be exploited through a zero-day, a leaked credential, or a logic flaw, and at that point the only defense left is watching what it actually does. eBPF is the technology that makes that watching cheap, safe, and comprehensive. It lets you run sandboxed programs inside the Linux kernel that observe every syscall, network connection, file access, and process execution — with almost no overhead and without loading a risky kernel module. In Kubernetes, eBPF has become the foundation for runtime security, and this guide explains how it works and how to use it.
Why eBPF changed runtime security
Before eBPF, deep kernel visibility meant writing a kernel module — code running with full kernel privileges that could crash the host if it had a bug. eBPF programs instead run in a restricted virtual machine inside the kernel, checked by an in-kernel verifier that rejects anything unsafe (unbounded loops, out-of-bounds memory access) before it ever loads. The result is that you can hook into kernel events — syscalls via tracepoints, function entry via kprobes, network events via the traffic-control and XDP layers — safely and with minimal performance cost. For security, that means you can see the ground truth of what a container does, at the kernel boundary the container cannot lie about, rather than trusting logs the workload itself emits.
What eBPF can see
Because it observes at the kernel, eBPF-based tooling sees the primitives that matter for detection:
- Process execution — every
execve, so a shell spawning inside a distroless container that should have none is immediately visible. - File access — reads and writes to sensitive paths like
/etc/shadow,/proc/self/exe, or mounted service-account tokens. - Network activity — outbound connections, so an unexpected connection to an external host or the cloud metadata endpoint stands out.
- Privilege changes — capability use,
setuid, and namespace changes that often accompany an escape attempt. - Syscall patterns — the raw signals underlying nearly every attack technique.
The tooling landscape
Three CNCF-associated projects dominate eBPF security in Kubernetes, with different emphases:
Falco is the runtime threat-detection engine. It consumes kernel events (via an eBPF probe) and evaluates them against a rules engine, emitting alerts when behavior matches a known-bad pattern. Its rules read almost like English:
- rule: Shell in container
desc: A shell was spawned inside a container
condition: >
spawned_process and container
and proc.name in (bash, sh, zsh, ash)
output: >
Shell spawned in container
(user=%user.name container=%container.name
image=%container.image.repository proc=%proc.cmdline)
priority: WARNING
tags: [container, shell, mitre_execution]
Tetragon, part of the Cilium project, does eBPF-based observability and in-kernel enforcement — it can not only detect a policy violation but kill the offending process directly from the kernel, closing the window between detection and response. Policies are expressed as TracingPolicy custom resources.
Cilium itself is the eBPF-based CNI, providing identity-aware network policy (including L7) and network observability with Hubble. It replaces iptables-based networking with eBPF datapaths, which is both faster and more securable.
A detection example worth having on day one
The single highest-value rule for most teams is "a shell should never start in a production container." Legitimate application containers do not spawn interactive shells; an attacker who has achieved code execution almost always does. With Falco, the rule above fires the moment bash or sh runs inside a container — a signal that maps directly to the MITRE ATT&CK execution phase and that image scanning could never have caught, because the image was clean.
From alert to enforcement
Detection is only useful if it drives a response. Build the pipeline deliberately:
- Baseline your workloads. Most services have a narrow, stable behavior profile. Tune rules so a legitimate batch job does not page someone at midnight.
- Route by severity. An escape indicator or a read of
/etc/shadowwarrants an immediate page; benign drift can go to a dashboard. - Enforce for high-confidence events. With Tetragon, a process that matches a never-legitimate pattern can be killed in-kernel automatically; a service-account token can be revoked and the pod quarantined.
- Feed detections back into prevention. A shell spawning in production is also evidence that the image should have been distroless and the pod should have had a read-only root filesystem — fix the class, not just the instance.
Operational notes
eBPF's overhead is low but not zero, and program compatibility depends on kernel version and configuration (CO-RE and BTF help portability across kernels). Managed Kubernetes distributions increasingly ship eBPF-friendly kernels, but verify before you rely on a specific probe. And remember that eBPF programs themselves require privilege to load, so the tooling that gives you visibility is also privileged — protect it accordingly.
Prevent-and-detect at a glance
| Layer | Prevent (pre-deploy) | Detect / enforce (runtime via eBPF) |
|---|---|---|
| Process | Distroless image, no shell | Alert or kill on unexpected exec |
| Filesystem | readOnlyRootFilesystem: true | Alert on writes to sensitive paths |
| Network | Deny-by-default policy | Observe and block anomalous egress |
| Privilege | Drop capabilities, non-root | Alert on capability/namespace changes |
| Identity | Minimal ServiceAccount | Alert on token/credential access |
How Safeguard helps
Runtime eBPF signals are most valuable when they connect back to the artifacts that produced them, instead of living in an isolated alert stream. Container security scanning hardens and inventories images before they deploy, so when a runtime tool flags an unexpected process, you can trace it to exactly what shipped in the image. Griffin AI correlates runtime detections with known vulnerabilities and reachability data, so an alert on a container running a reachable, exploitable CVE is escalated over background noise, and software composition analysis maps a flagged component back to every other workload that carries it. Prevention and detection reinforce each other: the cleaner your images and posture, the quieter and more meaningful your runtime alerts. Compare runtime-focused platforms in Safeguard vs Aqua, and review options on the pricing page.
You cannot patch a zero-day you have not seen yet — so watch the kernel. Create a free Safeguard account or read the documentation to connect runtime signals to the rest of your supply chain.