If you're running containers in production, runtime security isn't optional anymore — it's table stakes. Attack surfaces keep growing, threats are getting craftier, and your security team needs tools that work at the kernel level. We're talking about intercepting system calls, watching network activity, and catching suspicious behavior before it turns into a full-blown breach.
That's exactly where eBPF-based security tools have changed the game. Tools like Falco and Tetragon can observe every system call, file access, and network connection without touching your application code or tanking performance. Pretty remarkable when you think about it.
In this guide, I'll walk through both tools in depth — their architectures, how to install them, policy languages, performance characteristics, and when to pick one over the other. We'll also look at how eBPF runtime threat detection has matured into something genuinely production-ready, with both tools holding CNCF project status and seeing broad enterprise adoption.
One quick note: this article focuses on using eBPF-based tools to monitor and protect your infrastructure, not on defending against malicious eBPF programs themselves — that's a separate topic entirely. Whether you're evaluating these tools for the first time or tuning an existing deployment, the working examples below should help you make a solid decision.
What Is eBPF and Why It Matters for Runtime Security
Extended Berkeley Packet Filter (eBPF) is a technology built into the Linux kernel that lets sandboxed programs run in kernel space — no kernel modules or source code changes required. It started as a packet filtering mechanism, but honestly, it's evolved into something much bigger: a general-purpose in-kernel virtual machine that can trace system calls, monitor network flows, observe filesystem operations, and a whole lot more.
The way it works is pretty elegant. Programs written in restricted C get compiled to eBPF bytecode, verified by the kernel's built-in verifier for safety, and then attached to various hook points — kprobes, tracepoints, LSM hooks, or cgroup attachments.
For runtime security, eBPF brings several advantages that traditional approaches just can't match:
Kernel-level visibility. It sees every system call regardless of how an application is containerized or sandboxed. A process inside a Kubernetes pod can't evade eBPF-based monitoring because the monitoring happens below the container abstraction layer.
Minimal overhead. The verifier ensures programs terminate and won't crash the kernel, while JIT compilation delivers near-native execution speed.
No kernel modules needed. This is a big deal in environments where loading custom modules is restricted or considered too risky.
The typical security monitoring setup involves attaching eBPF programs to system call entry and exit points. When a process calls open(), execve(), connect(), or any other syscall, the eBPF program fires, collects context about the calling process (PID, UID, container ID, binary path), and either sends that event to userspace for analysis or makes an enforcement decision right there in the kernel. Both Falco and Tetragon build on this foundation, though they use it in fundamentally different ways.
Falco Deep Dive: Detection-First Runtime Security
Architecture and How It Works
Falco, a CNCF graduated project originally created by Sysdig, is best understood as a security camera for your infrastructure. It watches everything, matches events against a rich rule set, and fires alerts when something looks off. Importantly, Falco does not block or terminate processes — it detects and notifies. That's it.
This detection-first philosophy is actually a strength. If you've ever been woken up at 3 AM because a security tool killed a legitimate production process due to a misconfigured policy, you'll appreciate the approach.
Architecturally, Falco has three main components. First, the kernel-level data source captures raw system call events using one of several drivers. As of Falco v0.42.1 (released November 2025), the recommended driver is modern_ebpf, which uses CO-RE (Compile Once, Run Everywhere) technology to work across different kernel versions without per-kernel compilation. Second, the Falco libraries (libsinsp and libscap) enrich raw syscall data with metadata — resolving container IDs, Kubernetes pod names, usernames, and file paths. Third, the rules engine evaluates each enriched event against YAML-defined rules using a condition language based on Sysdig filter syntax.
Falco ships with over 93 default rules covering a broad range of threats: unexpected shell spawns in containers, sensitive file reads, privilege escalation attempts, outbound connections to known malicious IPs, and more. These rules deliver real value out of the box, which makes Falco particularly approachable for teams that want fast time-to-value without writing custom policies from scratch.
Installation on Kubernetes
Deploying Falco on Kubernetes is straightforward with the official Helm chart. The following commands install Falco with the modern eBPF driver, which is the recommended setup for kernels 5.8 and later.
# Add the Falcosecurity Helm repository
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
# Install Falco with modern_ebpf driver
helm install falco falcosecurity/falco \
--namespace falco \
--create-namespace \
--set driver.kind=modern_ebpf \
--set tty=true \
--set falcosidekick.enabled=true \
--set falcosidekick.webui.enabled=true \
--set collectors.kubernetes.enabled=true
# Verify the deployment
kubectl get pods -n falco
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=50The driver.kind=modern_ebpf flag is the important bit here. It tells Falco to use the CO-RE eBPF probe instead of the legacy kernel module or the older eBPF probe that required kernel headers. The modern driver is compiled once and works across compatible kernels, which dramatically simplifies deployment in heterogeneous environments. Enabling Falcosidekick gives you a flexible alert routing layer that can forward Falco alerts to Slack, PagerDuty, Elasticsearch, AWS Security Hub, and dozens of other destinations.
Writing Custom Falco Rules
Falco's default rules cover many common threats, but production environments almost always need custom rules tailored to specific applications and security policies. Rules are written in YAML with three primary elements: a rule name, a condition that defines when it triggers, and an output template for the alert message.
Here's a practical example — a pair of custom rules designed to detect container escape attempts and reverse shells:
# custom-rules.yaml — Detect container escape attempts
- rule: Detect Container Escape via nsenter or Host Namespace Access
desc: >
Detects attempts to escape container isolation by executing nsenter,
accessing host PID/network namespaces, or mounting the host filesystem.
These techniques are commonly used in container breakout attacks.
condition: >
spawned_process and container and
(
proc.name in (nsenter, unshare) or
(proc.name = mount and proc.args contains "/host") or
(proc.name = open and
(fd.name startswith /proc/1/ns/ or
fd.name startswith /proc/1/root/)) or
proc.args contains "--pid=host" or
proc.args contains "--network=host"
)
output: >
Container escape attempt detected
(user=%user.name command=%proc.cmdline container=%container.name
pod=%k8s.pod.name namespace=%k8s.ns.name
image=%container.image.repository parent=%proc.pname)
priority: CRITICAL
tags: [container, escape, mitre_privilege_escalation]
- rule: Detect Reverse Shell in Container
desc: >
Detects processes in containers that redirect stdin/stdout to a
network connection, which is a strong indicator of a reverse shell.
condition: >
spawned_process and container and
((proc.name in (bash, sh, dash, zsh, csh, fish)) and
(proc.args contains "/dev/tcp/" or
proc.args contains "socket" or
proc.cmdline contains "nc -e" or
proc.cmdline contains "ncat -e" or
proc.cmdline contains "bash -i"))
output: >
Reverse shell detected in container
(user=%user.name command=%proc.cmdline connection=%fd.name
container=%container.name pod=%k8s.pod.name
namespace=%k8s.ns.name)
priority: CRITICAL
tags: [container, reverse_shell, mitre_execution]To deploy these, you can mount them as a ConfigMap or pass them during Helm installation. The rules use Falco's filter syntax where fields like proc.name, proc.cmdline, fd.name, and container.name represent enriched event metadata. The spawned_process macro is a built-in shorthand matching execve syscalls, and the container macro filters for events inside containers rather than on the host. This layered approach — macros, lists, and rules — keeps complex detection logic readable and maintainable.
Alert Integration with Falcosidekick
Raw Falco alerts dumped to stdout aren't terribly useful in production. Falcosidekick fixes this by accepting Falco's alert stream and routing it to over 60 different output destinations.
For a typical enterprise setup, you might forward critical alerts to PagerDuty for immediate incident response, stream everything to Elasticsearch for long-term analysis, and push summary notifications to a Slack channel for the security team. The nice thing about this architecture is the clean separation — Falco focuses purely on high-fidelity detection, while Falcosidekick handles the messy business of routing, formatting, and delivering alerts to whatever tools your team already uses.
Tetragon Deep Dive: Detection Plus Enforcement
Architecture and How It Works
Tetragon, part of the Cilium project family and a CNCF project, takes a fundamentally different approach. If Falco is a security camera, Tetragon is a bouncer — it doesn't just observe suspicious activity, it can stop it on the spot. Tetragon's defining capability is in-kernel enforcement: it can send a SIGKILL signal to a process directly from eBPF code, terminating a threat before the offending system call even returns to userspace.
This happens in single-digit microseconds. Evasion is essentially impossible.
Tetragon v1.6.0 is the current stable release and includes several mature features. The operator now defaults to non-root with UID 65532, which reflects a security-hardened posture appropriate for production. Tetragon attaches eBPF programs to kprobes, tracepoints, and LSM hooks based on user-defined TracingPolicies — YAML documents specifying which kernel functions to monitor and what to do when conditions are met.
Here's where it gets interesting: unlike Falco, Tetragon ships with no default policies. This is deliberate. Tetragon expects you to define precisely what you want to monitor and enforce, rather than handing you a broad set of pre-built rules. Yes, this increases initial setup effort. But the payoff is a highly targeted monitoring configuration that generates minimal noise and uses minimal resources. Tetragon also natively understands Kubernetes — it resolves pod labels, namespaces, and service accounts without external enrichment, thanks to its integration with the Kubernetes API through the Cilium ecosystem.
Installation on Kubernetes
Tetragon is also deployed via Helm. Here's how to get it running with sensible production defaults:
# Add the Cilium Helm repository
helm repo add cilium https://helm.cilium.io
helm repo update
# Install Tetragon
helm install tetragon cilium/tetragon \
--namespace kube-system \
--set tetragon.grpc.address="localhost:54321" \
--set tetragon.exportFilename=/var/run/cilium/tetragon/tetragon.log
# Verify the deployment
kubectl get pods -n kube-system -l app.kubernetes.io/name=tetragon
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon \
-c tetragon --tail=50
# Install the tetra CLI for event observation
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
tetra getevents -o compactTetragon runs as a DaemonSet with one agent pod on each node. The tetra CLI is invaluable during development and debugging — it connects to Tetragon's gRPC interface and streams events in a human-readable format. Once the base install is running, you apply TracingPolicies as Kubernetes custom resources to tell Tetragon what to watch and how to respond.
Writing TracingPolicies: File Monitoring with Enforcement
TracingPolicies are the core of Tetragon's configuration. Each policy specifies kernel functions to trace, defines argument filters to narrow the scope, and optionally specifies enforcement actions. The following example monitors writes to sensitive files and terminates the offending process immediately — something Falco simply can't do.
# file-enforcement-policy.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: sensitive-file-write-enforcement
spec:
kprobes:
- call: "security_file_open"
syscall: false
args:
- index: 0
type: "file"
- index: 1
type: "int"
selectors:
- matchArgs:
- index: 0
operator: "Prefix"
values:
- "/etc/shadow"
- "/etc/passwd"
- "/etc/sudoers"
- "/etc/kubernetes/pki"
- "/var/run/secrets/kubernetes.io"
- index: 1
operator: "Equal"
values:
- "2" # O_RDWR — write access
matchActions:
- action: Sigkill
matchNamespaces:
- namespace: Pid
operator: NotIn
values:
- "host_ns"This policy hooks into security_file_open, which fires whenever a process tries to open a file. The matchArgs filter narrows it to specific sensitive paths opened with write access. When a match occurs inside a container (not on the host), Tetragon sends SIGKILL immediately — in-kernel, before the open call completes. The process never gets to write a single byte.
That's qualitatively different from Falco's approach, where the alert fires after the syscall has already executed and a separate response mechanism has to take action.
Writing TracingPolicies: Network Monitoring
Tetragon's network monitoring is equally capable. This policy monitors outbound connections from containers and can selectively block connections to suspicious destinations:
# network-monitoring-policy.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: network-connection-monitor
spec:
kprobes:
- call: "tcp_connect"
syscall: false
args:
- index: 0
type: "sock"
selectors:
- matchArgs:
- index: 0
operator: "DAddr"
values:
- "0.0.0.0/0"
matchActions:
- action: Post
matchNamespaces:
- namespace: Pid
operator: NotIn
values:
- "host_ns"
- call: "tcp_connect"
syscall: false
args:
- index: 0
type: "sock"
selectors:
- matchArgs:
- index: 0
operator: "DPort"
values:
- "4444"
- "1337"
- "6667"
- "8443"
matchActions:
- action: Sigkill
matchNamespaces:
- namespace: Pid
operator: NotIn
values:
- "host_ns"This combines monitoring with selective enforcement. All outbound TCP connections from containers get logged (the Post action), giving you visibility into network behavior. But connections to specific suspicious ports — commonly associated with reverse shells, C2 channels, and cryptomining pools — trigger an immediate SIGKILL. Broad visibility with surgical enforcement. I think that's a pretty compelling model.
Checking Events and Logs
For both tools, watching events in real time is essential during initial deployment and policy tuning. Here are the practical commands you'll need:
# === Falco Events ===
# Stream Falco alerts in real time
kubectl logs -n falco -l app.kubernetes.io/name=falco -f
# View alerts from the last hour filtered by priority
kubectl logs -n falco -l app.kubernetes.io/name=falco --since=1h \
| grep "Critical"
# Access the Falcosidekick UI (if enabled)
kubectl port-forward -n falco svc/falco-falcosidekick-ui 2802:2802
# === Tetragon Events ===
# Stream all Tetragon events in compact format
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
tetra getevents -o compact
# View Tetragon events from the export log
kubectl logs -n kube-system \
-l app.kubernetes.io/name=tetragon \
-c export-stdout --tail=100
# Parse Tetragon JSON events with jq for analysis
kubectl logs -n kube-system \
-l app.kubernetes.io/name=tetragon \
-c export-stdout --tail=100 | \
jq 'select(.process_exec != null) |
{binary: .process_exec.process.binary,
pod: .process_exec.process.pod.name,
namespace: .process_exec.process.pod.namespace}'The output format difference reflects each tool's philosophy. Falco produces human-readable alert strings following the output template in each rule. Tetragon emits structured JSON events with rich process lineage — including the full chain of parent processes, Kubernetes labels, and namespace context. Tetragon's JSON output is particularly well-suited for SIEM ingestion and security data lakes where automated correlation happens.
Falco vs Tetragon: Head-to-Head Comparison
So, let's get into the direct comparison. With both tools examined in detail, here's how they stack up across the dimensions that actually matter for production decisions.
| Dimension | Falco v0.42.1 | Tetragon v1.6.0 |
|---|---|---|
| CNCF Status | Graduated | Incubating (under Cilium) |
| Primary Function | Detection and alerting | Detection and enforcement |
| In-Kernel Enforcement | No — alert only | Yes — SIGKILL, Signal, Override |
| Default Rules/Policies | 93+ rules out of the box | None — must write TracingPolicies |
| CPU Overhead | Low to moderate (~10ms added latency) | Less than 1% |
| Memory Efficiency | Most efficient | Efficient |
| eBPF Driver | modern_ebpf (CO-RE), legacy module, legacy eBPF | Native eBPF with BTF support |
| Kubernetes Awareness | Enrichment via collectors | Native — labels, namespaces, service accounts |
| Policy Language | Sysdig filter syntax in YAML rules | TracingPolicy CRD (Kubernetes-native) |
| Alert Routing | Falcosidekick — 60+ outputs | JSON export, gRPC, Hubble integration |
| Best For | Broad detection, compliance, DoS detection | Enforcement, container escape prevention |
| Operator Security | Requires privileged container | Non-root default (UID 65532) as of v1.6.0 |
| Community Size | Larger — more third-party integrations | Growing — strong Cilium ecosystem |
Detection Capabilities
Both tools can detect a wide range of runtime threats, but their strengths diverge in some interesting ways. Research evaluating eBPF security tools across multiple attack scenarios has found that Tetragon excels at catching container escape attempts and cryptomining activity. Its ability to attach to specific kernel functions with fine-grained argument filtering means it catches subtle indicators that broader syscall-level monitoring might miss.
Falco, on the other hand, shows stronger results for denial-of-service detection. The breadth of its default rule set and event enrichment pipeline let it identify resource exhaustion patterns and anomalous system behavior more effectively.
There's also the out-of-the-box experience to consider. A freshly installed Falco immediately starts generating security-relevant alerts using its 93+ default rules. A freshly installed Tetragon? It monitors only basic process execution and exit events until you apply TracingPolicies. So Falco wins on time-to-value, while Tetragon rewards the upfront investment in policy authoring with more precise, lower-noise monitoring.
Performance and Resource Usage
Performance matters a lot when your security tool runs on every single node in a production cluster.
Tetragon's architecture is built for minimal overhead — independent benchmarks consistently measure less than 1% CPU impact even under high system call volumes. This efficiency comes from filtering events in-kernel: only events matching TracingPolicy selectors cross the kernel-userspace boundary, dramatically reducing data volume.
Falco's overhead is slightly higher — categorized as low to moderate. The modern eBPF driver captures a broader set of system calls and sends them to userspace for enrichment and rule evaluation, adding roughly 10 milliseconds of latency to the event pipeline. That's negligible for most workloads, but latency-sensitive applications might find even this overhead unacceptable. Falco compensates with superior memory efficiency — its userspace components are well-optimized and typically consume less memory than Tetragon's agent for equivalent monitoring scopes.
Kubernetes Integration
Tetragon has a clear edge here. Because it shares the Cilium ecosystem, Tetragon natively resolves Kubernetes pod labels, namespace names, service account identities, and container metadata without a separate enrichment step. TracingPolicies can select pods by label, enforce rules only in specific namespaces, and include full Kubernetes context in every event. You can write policies like "kill any process in the production namespace that opens a shell" directly — no complex filtering chains needed.
Falco gets to similar results but through a different path. Its Kubernetes metadata collectors query the API to enrich raw syscall events with container and pod information. This enrichment adds slight latency and can occasionally produce events with incomplete metadata if the lookup hasn't finished when the event is processed. In practice, this is rarely a problem in stable clusters, but it's an architectural difference worth knowing about.
Ecosystem and Community
Falco benefits from being a CNCF graduated project with a larger community and longer track record. The ecosystem includes Falcosidekick for alert routing, the Falco Rules repository for community-contributed detections, plugins for extending data sources, and broad integration with commercial security platforms. Finding examples and troubleshooting guidance is straightforward.
Tetragon's ecosystem is younger but growing fast, propelled by the Cilium project's popularity. Integration with Hubble for network observability, OpenTelemetry trace correlation support, and actively developed community TracingPolicy libraries are all expanding its reach. The Cilium Slack community is highly active, and the project ships meaningful feature additions with each release.
How to Choose: Decision Framework
This isn't a binary choice — but certain contexts and requirements do make one tool a better starting point. Here's how I'd think about it.
Go with Falco as your primary tool if: Your main goal is broad runtime visibility and compliance monitoring. You want something that works out of the box with minimal config. Your team is new to eBPF-based security and will benefit from pre-built rules. You need to route alerts to a wide variety of systems. You have non-Kubernetes workloads (bare metal, VMs) that need monitoring too. Or you're operating under compliance frameworks where demonstrable monitoring coverage matters — Falco's 93+ default rules and CNCF graduated status give you strong audit evidence.
Go with Tetragon as your primary tool if: You need in-kernel enforcement — killing processes or denying operations before they complete. Your environment is primarily Kubernetes and you want native label-aware policies. You're operating at scale and need the absolute lowest CPU overhead per node. Your team can write custom TracingPolicies and prefers precision over breadth. You're specifically worried about container escapes, cryptomining, or threats where immediate termination beats post-hoc alerting.
Go with both (honestly, the recommended approach) if: You want real defense in depth. You can manage two security tools operationally. You want Falco's broad detection catching what Tetragon's targeted policies might miss, and Tetragon's enforcement automatically neutralizing the most critical threats that Falco can only alert on. This complementary model is increasingly recognized as best practice in cloud-native security.
Using Falco and Tetragon Together
The strongest runtime security posture uses both tools in a complementary deployment. This isn't redundancy — it's defense in depth, where each tool covers gaps in the other's design.
In this setup, Falco serves as the broad detection layer. Its 93+ default rules monitor for suspicious activities across the entire syscall surface. Every alert feeds into your SIEM or security data lake via Falcosidekick, providing comprehensive audit trails and giving analysts full context for investigations. Falco catches the unexpected — novel attack patterns, subtle policy violations, anomalies that don't match any predefined enforcement policy.
Tetragon serves as the enforcement layer. For well-understood threats where the correct response is always termination — container escapes, writes to critical system files, connections to known malicious infrastructure, cryptocurrency miner execution — Tetragon's TracingPolicies provide immediate, automatic remediation. The process is killed in-kernel before it completes its action. No window of vulnerability between detection and response.
From a resource standpoint, this combined deployment is viable on production clusters. Tetragon's sub-1% CPU overhead plus Falco's efficient memory usage means running both on every node doesn't significantly impact workload performance. The key is clear role separation: don't duplicate detection logic in both tools. Use Falco for breadth and auditability, Tetragon for depth and enforcement.
A practical implementation might look like this: Falco runs its full default rule set plus custom rules for your compliance requirements, generating alerts for investigation. Tetragon runs a focused set of TracingPolicies targeting your highest-priority threats — container escapes, sensitive file modifications, suspicious port connections — with SIGKILL enforcement. Falco alerts flow to your SIEM. Tetragon events flow to your incident response platform. The two streams get correlated in your SIEM for a unified view of detected and blocked threats.
Tracee: The Third Option Worth Knowing
While Falco and Tetragon dominate this space, Tracee by Aqua Security deserves a mention. It's an open-source runtime security and forensics tool that uses eBPF to trace system calls, kernel functions, and network activity. It includes behavioral detection signatures and can capture forensic artifacts for post-incident analysis.
Tracee's standout feature is its focus on security research and forensics. It provides detailed process trees, file operation histories, and network connection records that are invaluable for understanding the full scope of an incident. It also includes built-in signatures for common attack techniques mapped to the MITRE ATT&CK framework.
The catch? Performance. Independent benchmarks show Tracee introduces significantly higher overhead than either Falco or Tetragon — we're talking 110 to 114 milliseconds of added latency in comparable tests. Memory consumption is also the highest of the three. That makes Tracee less suitable for always-on production monitoring on performance-sensitive workloads, but potentially valuable as a forensic tool deployed on-demand during incident investigations, or in dev/staging environments where the overhead is acceptable.
For organizations evaluating all three, the practical recommendation is: use Falco and Tetragon for production runtime security, and consider Tracee as a supplementary forensics capability when deeper investigation is needed.
Shared Limitations: When eBPF Security Monitoring Falls Short
Despite all the power of eBPF-based runtime security, you should understand its fundamental limitations. Both Falco and Tetragon — and every eBPF security tool — share a critical assumption: that the Linux kernel is a trustworthy observer.
eBPF programs run inside the kernel and rely on it to accurately report syscall arguments, process metadata, and file paths. If an attacker achieves kernel-level code execution — through a kernel exploit, malicious module, or compromised eBPF program — they can potentially tamper with what security tools observe. That's not a theoretical concern, either. Kernel vulnerabilities are discovered regularly, and sophisticated attackers specifically target the kernel to evade monitoring. Rootkits operating at the kernel level can hide processes, files, and network connections from everything, including eBPF-backed tools.
This is why eBPF runtime security should be one layer in a broader defense strategy that includes kernel hardening (disabling unnecessary modules, Secure Boot, kernel lockdown mode), immutable infrastructure practices (read-only root filesystems, signed container images), network segmentation, and hardware-based attestation where available.
There's also the kernel version dependency. Both tools need relatively modern kernels for the best experience — 5.8+ for Falco's modern eBPF driver, 5.3+ with BTF support for Tetragon. Organizations stuck on older kernels (common in enterprise environments with long release cycles) may need Falco's legacy kernel module driver, sacrificing CO-RE's portability benefits.
Finally, eBPF tools can't easily inspect encrypted data contents. They see system calls and arguments, but if an application encrypts data before writing or sends encrypted payloads over the network, the eBPF programs see only encrypted bytes. Monitoring TLS-protected traffic requires additional techniques like attaching to userspace SSL library functions — both tools support this to varying degrees, but it adds complexity and potential compatibility issues across TLS implementations.
Frequently Asked Questions
What is eBPF security monitoring and how does it work?
eBPF security monitoring uses extended Berkeley Packet Filter technology to attach small, verified programs to kernel hook points — syscall entry/exit points, network stack functions, LSM hooks, and others. When a monitored event occurs (a process spawns, a file is opened, a network connection is made), the eBPF program fires, collects contextual data, and either sends it to a userspace agent for analysis or makes an enforcement decision directly in the kernel. This provides deep visibility into system behavior without kernel modifications, application instrumentation, or significant performance overhead. Falco and Tetragon build user-friendly layers on top of this, providing rule engines, policy languages, and integrations with alerting and incident response systems.
Is Falco or Tetragon better for Kubernetes runtime security?
Neither is universally better — they serve different purposes. Falco excels at broad detection with 93+ default rules that provide immediate visibility, making it ideal for compliance monitoring, audit logging, and detecting a wide range of threats with minimal setup. Tetragon excels at targeted enforcement, killing malicious processes in-kernel before they complete their actions — ideal for preventing container escapes, blocking cryptomining, and enforcing file integrity. For Kubernetes specifically, Tetragon has an edge in native integration with pod labels, namespaces, and service accounts. The strongest approach for production Kubernetes in 2026 is running both together: Falco for detection breadth, Tetragon for enforcement depth.
Can Falco and Tetragon run together on the same cluster?
Yes, and it's actually the recommended approach. They use independent eBPF programs attached to different hook points, and the Linux kernel supports multiple eBPF programs on the same hooks without interference. The combined CPU overhead is manageable — Tetragon adds less than 1% and Falco adds a low to moderate amount. The key to a successful combined deployment is clear role separation: configure Falco for broad detection and alerting, Tetragon for targeted enforcement on your highest-priority threats. Don't duplicate detection logic in both tools — that just creates redundant processing and alert fatigue.
What Linux kernel version is needed for eBPF security tools?
Requirements vary by tool and driver. Falco's modern eBPF driver (recommended) needs kernel 5.8+ with BPF CO-RE support. The legacy eBPF probe works on 4.14+ but requires kernel headers on each node. Tetragon needs 5.3+ and benefits significantly from BTF support (typically 5.4+ when enabled at compile time). For the best experience with either tool — LSM hooks, CO-RE portability, latest eBPF features — kernel 5.15+ (an LTS release) is recommended. Most major Kubernetes distributions and cloud providers now ship kernels that meet or exceed these requirements.
How does eBPF runtime threat detection compare to traditional IDS?
Traditional IDS tools like Snort or Suricata primarily monitor network traffic, matching packets against signature databases. eBPF runtime detection operates at a fundamentally different layer — it monitors system calls, process executions, file operations, and kernel function invocations from inside the kernel itself. This means eBPF tools detect threats that never produce distinctive network signatures: privilege escalation via misconfigured SUID binaries, container escapes through namespace manipulation, sensitive file reads by compromised processes, and malicious activity over encrypted channels invisible to network IDS. eBPF tools like Tetragon can also enforce policies in real time, while traditional IDS can only alert or block source IPs after the fact. The trade-off is that eBPF tools are host-based and must run on every monitored node, while network IDS can monitor at chokepoints. For comprehensive security, the two approaches complement each other well, and many organizations deploy both as part of a defense-in-depth strategy.