Kubernetes runtime security has quietly changed its foundation over the last five years, and eBPF is the reason. What used to require a kernel module, a privileged sidecar, or a ptrace-based agent bolted onto every node can now run as a verified, sandboxed program inside the Linux kernel itself — reading syscalls, network events, and file activity with sub-millisecond overhead. Aqua Security has leaned into this shift with Tracee, its open-source eBPF runtime detection engine first released in 2019, and it's a useful lens for understanding where eBPF actually helps and where it doesn't. This post breaks down what eBPF is doing inside Kubernetes clusters today, how vendors like Aqua use it, what the real performance and coverage tradeoffs are, and where teams still need something eBPF was never designed to provide: proof of what went into the container image before it ever reached a node.
What Is eBPF, and Why Did It Become the Default Lens for Kubernetes Runtime Security?
eBPF (extended Berkeley Packet Filter) lets you run sandboxed, verified programs inside the Linux kernel without writing a kernel module or recompiling anything, and Kubernetes security vendors adopted it because it sees everything a workload does at the syscall level with near-zero overhead. The technology traces back to Linux kernel 3.18 in 2014, but it became a security-relevant platform once projects like Cilium (started by Isovalent in 2016) and Falco (open-sourced by Sysdig, also 2016) proved it could power network policy and threat detection in production. Aqua Security followed the same path with Tracee, moving away from earlier ptrace- and kernel-module-based instrumentation toward eBPF probes that hook directly into the kernel's tracepoints and LSM (Linux Security Module) framework. The appeal is structural: one eBPF program attached at the kernel boundary can observe every container on a node — process execution, file opens, network connections — without injecting an agent into each pod's namespace.
How Does eBPF Change What Aqua Security and Similar Vendors Can Detect Compared to Older Agent-Based Scanning?
eBPF gives runtime tools kernel-level visibility into behavior that container-layer scanning simply cannot see, such as a process executing from /tmp after a reverse shell lands, or a container reading /etc/shadow outside its expected file access pattern. Aqua's Tracee, for example, ships detection signatures for behaviors like anti-debugging techniques, unexpected ptrace calls, and container escape attempts via cgroup release_agent abuse (the technique behind CVE-2022-0492). Before eBPF, catching this required either a privileged agent making ptrace syscalls against every monitored process — which adds real latency and a large attack surface of its own — or relying purely on image scanning, which tells you nothing about what a container actually does once it's running. The tradeoff vendors are making is visibility depth versus deployment friction: eBPF programs still need a DaemonSet with elevated capabilities (typically CAP_BPF and CAP_PERFMON, or CAP_SYS_ADMIN on older kernels) on every node, so "no agent" is a marketing simplification, not a technical reality.
Does eBPF Actually Eliminate the Performance Tax That Kubernetes Teams Feared From Security Tooling?
Mostly yes for CPU and network overhead, but not universally, and the numbers depend heavily on what you're hooking. Cilium's own benchmarks and independent tests have shown eBPF-based network dataplanes adding roughly 1-5% CPU overhead compared to 15-30% overhead reported for iptables-heavy or sidecar-proxy service mesh configurations at high request volumes. Runtime security tracing is a different story: hooking every execve, openat, and network syscall across a busy node with hundreds of short-lived processes can meaningfully increase kernel-to-userspace event volume, which is why most vendors, including Aqua and Falco, ship configurable rule sets rather than tracing everything by default. A cluster running 200+ pods per node with verbose file-integrity tracing enabled can still see measurable CPU contention if the userspace consumer (the daemon reading the ring buffer) can't keep up — the kernel-side hook is cheap, but the pipeline behind it isn't free.
Can eBPF-Based Tools Stop an Attack in Real Time, or Only Observe It After the Fact?
It depends entirely on whether the tool uses eBPF for observation or for enforcement, and most Kubernetes eBPF tooling historically has been the former. Falco, still one of the most widely deployed eBPF-based tools (a CNCF graduated project as of 2023), is fundamentally a detection engine — it emits alerts, and blocking an action requires wiring those alerts into a separate response system, often with seconds of lag. Enforcement became practical once LSM-based eBPF hooks (BPF-LSM, stabilized in kernel 5.7, released May 2020) let programs return a decision that the kernel actually obeys, not just a log line after the fact. Cilium Tetragon, released in 2022, was built specifically around this capability to kill a process or block a syscall synchronously. Aqua's Tracee remains primarily detection-oriented; Aqua's blocking capabilities for container behavior largely live in its separate Enforcer agent rather than in the eBPF detection layer itself. The practical takeaway for security teams: "eBPF-powered" does not automatically mean "can stop the attack" — verify whether a given feature is a detector or an enforcer before you rely on it during an incident.
What Blind Spots Remain Even With Best-in-Class eBPF Runtime Tooling?
eBPF only sees what happens at runtime on a kernel it can instrument, which leaves at least three categories of Kubernetes risk uncovered. First, kernel compatibility: full BPF-LSM enforcement needs kernel 5.7+, and many managed Kubernetes node pools (older Amazon Linux 2 AMIs, some Bottlerocket configurations) still ship kernels that only support a subset of eBPF program types, silently degrading a vendor's advertised feature set. Second, serverless and VM-isolated node types — AWS Fargate, Azure Container Instances, GKE Autopilot's gVisor-sandboxed pods — restrict or entirely block the privileged access eBPF agents need, meaning a significant and growing share of production Kubernetes workloads have no eBPF visibility at all. Third, and most importantly for supply chain risk: eBPF tells you what a container did after it started running. It has no opinion on what was compiled into that image, whether a dependency was tampered with during the build, whether the image was signed by a legitimate pipeline, or whether the base image itself shipped with a backdoored package. A cryptominer injected into a build via a compromised CI runner looks, at the syscall level, almost identical to legitimate compute-heavy application code until it starts talking to a mining pool — by which point the workload has already been running with valid credentials for however long it took to notice.
How Safeguard Helps
Runtime detection, including eBPF-based detection, answers "what is this workload doing right now" — it can't answer "should I trust what's in this image in the first place." Safeguard is built around that second question. We track software provenance and build integrity from source commit through to the artifact that actually gets deployed into your Kubernetes clusters, so you have a verifiable chain of custody — SBOMs, signed attestations, dependency provenance — before an image is ever scheduled onto a node. That matters because eBPF runtime tools, Aqua's Tracee included, are reactive by design: they catch malicious behavior after a compromised or vulnerable artifact is already executing, at which point you're doing incident response instead of prevention.
Safeguard complements runtime eBPF tooling rather than replacing it. We flag risky dependencies, unsigned or tampered build artifacts, and known-vulnerable base images at admission time — before the syscalls that an eBPF probe would eventually flag ever get made. For teams already running Falco, Tetragon, or Aqua's eBPF-based stack for runtime visibility, Safeguard closes the gap upstream: fewer compromised images reach your nodes in the first place, so your runtime detection layer spends its alert budget on genuine anomalies instead of the aftermath of a supply chain gap that could have been caught at build time. If you're evaluating eBPF-based runtime security as part of a broader Kubernetes security strategy, the question worth asking any vendor — Aqua included — is not just "what can you see at runtime," but "what can you prove about this artifact before it runs." That's the layer Safeguard is built to own.