Tetragon: eBPF Security Observability with Kubernetes-Aware Runtime Enforcement

The Problem Tetragon Solves: Kernel-Level Events with Kubernetes Context

Most security tools either work in userspace, which misses low-level kernel activity, or they generate raw kernel events that are hard to correlate with workloads. Tetragon sits in the kernel via eBPF and enriches events with Kubernetes metadata. This means you can answer questions like: which pod executed this binary, or which namespace accessed that file. The README lists process execution, system call activity, and I/O including network and file access as the core event types. This is for platform teams and security engineers who need real-time visibility into workload behavior without losing the container and pod identity. It is not for simple host-based monitoring; it is built around Kubernetes identities.

How Tetragon Works: Sensors, eBPF, and Kubernetes Awareness

Tetragon uses eBPF hooks in the kernel, which it calls sensors, to observe critical events. The README describes two main event categories. First, process lifecycle events: process_exec and process_exit are generated by default, giving full process lifecycle observability. Second, generic tracing: process_kprobe, process_tracepoint, and process_uprobe events cover custom use cases like network observability, filename access, credentials monitoring, and privileged execution. The key mechanism is that events are not just kernel traces; they are enriched with Linux and Kubernetes metadata. This is a differentiator: the eBPF programs run in the kernel, but the event schema includes pod names and namespaces, which requires coordination with the Kubernetes API. The architecture is not fully detailed in the README, but the sensor model suggests a modular approach where different hooks can be enabled or disabled.

Getting Tetragon Running: Kubernetes, Docker, and the Tetra CLI

The README points to official docs for getting started, with four specific paths. You can try Tetragon on Kubernetes, on Linux via Docker, deploy it in a cluster, or install the Tetra CLI. The exact commands are not in the README, but the structure implies a standard Helm chart or manifest-based deployment for Kubernetes, and a Docker image for Linux. The Tetra CLI is a separate tool for interacting with Tetragon, likely for viewing events or managing policies. From the README, you should expect to install Tetragon as a DaemonSet or similar, then use TracingPolicy resources to define what to trace. The getting started guides are the authoritative source; the README gives no quick-start command, so the first verification step is to follow those guides.

TracingPolicy: The Core Configuration Mechanism

Tetragon's advanced use cases depend on TracingPolicy, which is a Kubernetes custom resource. The README links to a TracingPolicy concept page, indicating that this is how you define custom kprobe, tracepoint, or uprobe events. For example, to monitor filename access or credentials, you write a TracingPolicy that specifies which hooks to attach and what to filter. This is a powerful model because it allows declarative configuration of kernel tracing, but it also introduces complexity. You need to understand eBPF concepts and the kernel hooks you are targeting. The default process_exec and process_exit events require no policy, so you get basic lifecycle visibility out of the box. For anything beyond that, you must write and manage TracingPolicy CRDs, which is a significant operational burden for teams without eBPF experience.

A Genuine Limitation: eBPF Dependencies and Kernel Compatibility

Tetragon's reliance on eBPF is both its strength and its constraint. eBPF programs require a Linux kernel with BPF support enabled, and specific features like kprobes and tracepoints must be available. On older kernels or hardened environments, Tetragon may not function or may require additional privileges. The README does not specify minimum kernel versions, but this is a known consideration for any eBPF tool. Also, because Tetragon runs in the kernel, any bug in the eBPF programs could affect system stability, though the project mitigates this with rigorous testing. For non-Linux systems, Tetragon is not an option. If you need to monitor Windows containers or run in a managed environment that restricts eBPF, this is the wrong tool. You should verify your kernel's capabilities before committing.

Alternative: Falco and Its Userspace Approach

A common alternative to Tetragon is Falco, which also does runtime security monitoring but takes a different approach. Falco uses eBPF or kernel modules to collect syscalls, but it ships with a rich set of default rules and a userspace engine that evaluates events against those rules. Tetragon, by contrast, is more tightly integrated with Kubernetes and requires you to define TracingPolicies for custom events. Falco's rule language is a separate DSL, while Tetragon uses Kubernetes CRDs. The key difference is that Falco is more mature in terms of prebuilt detection rules, while Tetragon focuses on deep eBPF observability with native Kubernetes identity. If you want a drop-in detection tool with minimal configuration, Falco may be easier. If you want fine-grained kernel tracing with pod context, Tetragon is more direct.

Maintenance and License Considerations

Tetragon is licensed under Apache-2.0, which is permissive for commercial use and modification. The project is actively maintained, with v1.7.1 released recently and a regular release cadence (v1.7.0 in April, v1.6.1 in March). This suggests a healthy development cycle. However, the README does not detail upgrade procedures or migration costs. Given the eBPF kernel integration, upgrades may require recompiling or reloading BPF programs, and changes in kernel interfaces could affect compatibility. The project has a contribution guide and a USERS.md file listing adopters, but the README does not specify how to handle version upgrades. You should plan to test upgrades in a staging cluster, especially when moving between minor versions, as TracingPolicy APIs may change.

Who Should Adopt Tetragon and What to Verify First

Tetragon is a strong fit for Kubernetes-native security teams that need real-time process and I/O observability with pod-level context. It is also suitable for organizations already using Cilium, given the shared lineage. Teams without eBPF expertise may find the TracingPolicy learning curve steep. Before adoption, verify that your kernel supports the required eBPF features, that your cluster can run privileged DaemonSets, and that you have a way to manage TracingPolicy CRDs. Test the default process lifecycle events first, then experiment with a simple TracingPolicy for file access. The README does not provide a quick-start command, so rely on the official getting started guides. If you need a solution for non-Linux or heavily restricted environments, look elsewhere.

Editorial conclusion

Adopt Tetragon if you run Kubernetes and need deep, kernel-level security observability with native pod and namespace context, and if you want to enforce policies directly in the kernel via eBPF. Do not adopt it if you need a purely userspace agent or if your workloads run on non-Linux platforms. Before deploying, verify that your kernel supports the required eBPF features and that your security team can manage TracingPolicy CRDs. Test with the getting started guides on a non-production cluster first.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes