eBPF (extended Berkeley Packet Filter) has become the foundational technology for modern container runtime security. Tools like Falco, Tetragon, and Cilium use eBPF to observe kernel-level events in real time: system calls, network connections, file accesses, process executions. The visibility eBPF provides into what is actually happening inside running containers is unprecedented in the history of container security tooling.
Understanding what eBPF-based security does well — and the specific limitations that require complementary controls — is the foundation of an effective runtime security architecture.
What eBPF Enables for Container Security?
eBPF programs attach to kernel hooks and observe system calls, network operations, and other kernel events without modifying the kernel itself. For container security, this means:
Syscall tracing without agent overhead: Traditional security agents that intercept system calls have significant performance costs. eBPF programs run in kernel space with minimal overhead (typically under 1% CPU overhead at normal workload levels).
Immutable observation: Unlike agents that can be killed by a compromised process, eBPF programs running in kernel space cannot be easily disabled from user space. A container that kills a user-space security agent cannot kill the kernel-level eBPF program watching it.
Complete kernel-level visibility: Every system call made by every process in every container on the host is observable via eBPF. No process can hide its kernel interactions from eBPF monitoring.
Network-level visibility: eBPF programs can observe every packet, every connection, every socket operation. Combined with container metadata (which pod is making this connection?), this provides complete network observability.
The Detection Model: Observe, Baseline, Alert
eBPF tools implement container security detection through a common pattern:
- Observe: Capture kernel events (system calls, network events, file operations) for all containers
- Baseline: Understand what normal looks like for each container workload
- Alert: Flag deviations from the baseline or matches to known-bad patterns
Falco implements this through a rule language where you define what “bad” looks like and alert when it matches. Tetragon extends this with enforcement policies that can kill processes or drop network connections when conditions are met.
The limitation: the rules or baseline must be defined. Out-of-the-box eBPF security tools come with generic rules that catch common attack patterns. Application-specific rules that catch workload-specific anomalies require workload-specific knowledge and tuning.
The Event Volume Problem
eBPF’s comprehensive visibility creates an event volume challenge. A busy container environment generates millions of kernel events per minute. All of these events need to be evaluated against rules and baselines.
Event volume creates two problems:
Processing overhead: Even at less than 1% CPU overhead per event, millions of events per minute sum to significant processing load. eBPF tool configurations must tune which events to capture and which to filter to manage this overhead.
Alert signal-to-noise: Generic rules against high-volume events produce high-volume alerts. Security teams that must manually review thousands of daily alerts from an eBPF tool stop reviewing them. The tool produces the alerts; the alerts are ignored; the security capability is impaired.
Image hardening directly reduces the event volume that eBPF tools must process. A hardened container with 40 packages generates fewer distinct system call patterns than an unhardened container with 400 packages. Fewer installed packages means fewer processes, fewer file accesses, and a smaller behavioral space to observe. The eBPF monitoring load is proportionally reduced.
Detection vs. Prevention: The Critical Gap
Container security through eBPF is primarily detective, not preventive (with some exceptions — Tetragon supports enforcement policies that can block operations). The core capability is observation and alerting.
This means:
eBPF detects malicious execution. If an attacker runs a shell in a container, eBPF sees it. If they make an unexpected network connection, eBPF sees it. The detection happens in near-real-time.
eBPF does not prevent the malicious code from being present. The shell that the attacker executes is present in the container image. The exploitation of a CVE in a package is possible because the package is in the image. eBPF can detect the exploitation; it cannot prevent the exploitable code from being present.
Container hardening addresses the prevention dimension. Removing the shell from the container image means the attacker cannot run a shell even if eBPF misses detecting their initial access. Removing the vulnerable package means the CVE cannot be exploited.
The combination of detection and prevention is more robust than either alone:
- Detection without prevention: eBPF fires an alert when the attacker uses the shell. The attack has already occurred; the question is response time.
- Prevention without detection: The image is hardened, but if an attacker finds a way around the hardening, there is no detection mechanism.
- Detection plus prevention: The hardened image makes the attack harder; the eBPF detection catches deviations from the hardened baseline.
Frequently Asked Questions
What is eBPF-based container runtime security and how does it work?
eBPF (extended Berkeley Packet Filter) programs attach to Linux kernel hooks and observe system calls, network operations, file accesses, and process executions in real time without modifying the kernel. For container runtime security, tools like Falco and Tetragon use eBPF to provide complete kernel-level visibility into every container on a host with typically less than 1% CPU overhead, and unlike user-space agents they cannot be killed by a compromised container process.
What are the limitations of eBPF-based container runtime security?
eBPF-based container runtime security is primarily detective rather than preventive—it observes and alerts on malicious behavior but does not prevent exploitable code from being present in container images in the first place. The comprehensive visibility also creates an event volume challenge: millions of kernel events per minute must be evaluated against rules, and without application-specific tuning, generic rules produce high-volume alerts that security teams stop reviewing.
How does eBPF container runtime security complement image hardening?
eBPF detects malicious execution after it occurs, while image hardening prevents exploitable code from being present at all. When both controls are combined, a hardened image removes the shell an attacker might try to run, and eBPF detects any deviation from the known-minimal behavioral profile. The hardened baseline makes eBPF detection more precise because the legitimate behavioral space is smaller—every unexpected process in a hardened container warrants investigation.
Does image hardening reduce the performance overhead of eBPF monitoring?
Yes. A hardened container with fewer installed packages generates fewer distinct system call patterns, fewer processes, fewer file accesses, and a smaller behavioral space to observe. This directly reduces the volume of kernel events the eBPF monitoring infrastructure must process, improving signal-to-noise ratio and reducing processing overhead proportionally to the reduction in package footprint.
Practical Architecture for eBPF + Image Hardening
The integration pattern for combined eBPF and image hardening:
Build pipeline: Runtime profiling during CI/CD captures the expected behavioral profile (processes, syscalls, network connections, file accesses). Image hardening removes unused packages. The profile data informs both the hardening decision and the eBPF rule configuration.
Deployment: Hardened images deploy with eBPF monitoring configured to the expected behavioral profile. Deviations from the profile generate alerts.
Alert response: When an eBPF alert fires on a hardened container, the deviation from the known-minimal behavioral profile is highly significant. An unexpected process in a hardened container that was built to have no shell is a stronger signal than an unexpected process in an unhardened container with a full shell environment.
The hardened baseline makes eBPF detection more precise because the legitimate behavioral space is smaller and better defined. Every deviation from the hardened profile warrants investigation because the profile was deliberately constructed to be minimal.
