Tetragon — eBPF-Based Security Observability for Kubernetes
Tetragon provides real-time security observability and runtime enforcement using eBPF, giving deep visibility into process, file, and network activity in Kubernetes.
Installation agent prête
Cet actif peut être installé après choix du runtime, vérification du plan et exécution de la commande adaptée.
npx -y tokrepo@latest install f0c89b76-3997-11f1-9bc6-00163e2b0d79 --target codexÀ exécuter après confirmation du plan en dry-run.
What it is
Tetragon is a security observability and runtime enforcement tool built on eBPF. Developed by the Cilium/Isovalent team, it hooks directly into the Linux kernel to monitor process execution, file access, and network connections in real time. When deployed on Kubernetes, it provides deep visibility into container and pod behavior without modifying application code.
It is designed for security engineers, platform teams, and SREs who need runtime threat detection and policy enforcement at the kernel level.
The project is actively maintained with regular releases and a growing user community. Documentation covers common use cases, and the open-source nature means you can inspect the source code, contribute fixes, and adapt the tool to your specific requirements.
How it saves time or tokens
Tetragon replaces multiple security agents (process monitors, file integrity checkers, network sniffers) with a single eBPF-based sensor. Because it operates in-kernel, there is no user-space context switching overhead. Security policies are defined as Kubernetes CRDs, fitting into GitOps workflows without custom scripting.
How to use
- Install Tetragon on your Kubernetes cluster via Helm chart (
helm install tetragon cilium/tetragon). - Apply TracingPolicy CRDs to define which system calls, file paths, or network events to monitor.
- View security events through
tetraCLI, JSON logs, or forward them to your SIEM via gRPC export.
Example
# TracingPolicy: alert on any process executing in /tmp
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: detect-tmp-exec
spec:
kprobes:
- call: security_bprm_check
syscall: false
args:
- index: 0
type: linux_binprm
selectors:
- matchArgs:
- index: 0
operator: Prefix
values:
- /tmp/
Related on TokRepo
- DevOps AI tools -- Infrastructure and DevOps tooling on TokRepo.
- Security AI tools -- Security-focused tools and workflows.
Common pitfalls
- Tetragon requires a Linux kernel version 5.4+ with BTF (BPF Type Format) support. Older kernels or minimal container OS images may lack BTF.
- Overly broad TracingPolicies (e.g., tracing all syscalls) generate excessive event volume and can impact node performance.
- eBPF program verification failures produce cryptic kernel errors. Start with the example policies and iterate.
- Tetragon's enforcement mode (killing processes that violate policy) is powerful but can break legitimate workloads if policies are too aggressive.
- JSON event logs are verbose. Configure log rotation or streaming to an external system to avoid filling node disks.
Before adopting this tool, evaluate whether it fits your team's existing workflow. Read the official documentation thoroughly, and start with a small proof-of-concept rather than a full migration. Community forums, GitHub issues, and Stack Overflow are valuable resources when you encounter edge cases not covered in the documentation.
Questions fréquentes
eBPF (extended Berkeley Packet Filter) allows sandboxed programs to run inside the Linux kernel without modifying kernel source code. Tetragon uses eBPF to intercept system calls and kernel events at near-zero overhead, providing security observability without kernel modules or user-space proxies.
Both are runtime security tools for Kubernetes. Falco uses a kernel module or eBPF probe to detect threats based on rules. Tetragon uses eBPF natively and adds runtime enforcement (process killing), not just detection. Tetragon policies are Kubernetes CRDs, while Falco uses YAML rules.
Tetragon supports both monitoring and enforcement. In enforcement mode, it can kill processes, deny file access, or block network connections that violate a TracingPolicy. This happens in-kernel before the action completes.
Yes. Tetragon can run as a standalone daemon on any Linux host with eBPF support. Kubernetes integration adds CRD-based policy management and pod-aware event labeling, but the core eBPF sensors work on bare-metal Linux.
Tetragon's eBPF programs run in-kernel with minimal overhead, typically under 1% CPU for standard policies. Performance depends on the number and complexity of TracingPolicies. High-frequency syscall tracing on busy nodes will increase overhead.
Sources citées (3)
- Tetragon GitHub— Tetragon provides eBPF-based security observability
- eBPF.io— eBPF technology overview
- Cilium Docs— Cilium project and eBPF networking
En lien sur TokRepo
Fil de discussion
Actifs similaires
Hubble — Network Observability for Kubernetes via eBPF
A CNCF observability tool built on Cilium that provides deep visibility into network traffic, service dependencies, and security policies in Kubernetes clusters.
Cilium — eBPF-Powered Cloud Native Networking & Security
Cilium provides high-performance networking, observability, and security for Kubernetes using eBPF. CNI plugin, service mesh, and network policy — all kernel-level.
Pixie — eBPF-Based Auto-Instrumentation for Kubernetes Observability
CNCF observability platform that uses eBPF to capture metrics, traces, and logs from every pod with zero code changes.
Calico — Kubernetes Networking and Network Security
A high-performance networking and network policy engine for Kubernetes that provides pod networking, network policy enforcement, and optional eBPF data plane for zero-overhead observability.