Tetragon: Runtime Security with eBPF

By Kokil Thapa | Last reviewed: August 2026

Traditional web application firewalls and static analysis tools miss attacks that happen inside the kernel or during legitimate process execution. Tetragon: Runtime Security with eBPF solves this by observing and enforcing security policies directly at the operating system level, independent of your application code. For developers managing Laravel APIs, WordPress sites, or microservices on Linux servers, understanding this tool is now essential for defense-in-depth. If you are evaluating infrastructure hardening alongside server security best practices, Tetragon provides the missing visibility layer between your application and the kernel.

What Is Tetragon: Runtime Security with eBPF and How Does It Work?

Tetragon is not another log aggregator or intrusion detection system that reacts after the fact. It is a proactive enforcement engine built on eBPF (extended Berkeley Packet Filter). In my experience maintaining production Linux environments for legal-tech portals and eCommerce platforms, the gap between "application secure" and "kernel secure" is where most sophisticated breaches occur. Tetragon bridges this gap by attaching probes directly to kernel functions.

Unlike traditional auditd or strace, which can impose significant performance penalties, eBPF programs run in a sandboxed virtual machine within the kernel. They verify safety before execution, meaning they cannot crash the host system. Tetragon leverages this to provide deep observability and enforcement with typically less than 3% CPU overhead on modern kernels (Linux 5.15+ recommended for full feature support).

The architecture operates in three distinct phases. First, eBPF hooks capture raw syscall data (execve, openat, connect) with zero-copy efficiency. Second, the Tetragon agent in user space correlates these events with process genealogy, container metadata, and loaded policies. Third, it either logs the enriched event or signals the kernel to block the action immediately. This separation ensures that complex policy logic doesn't block the hot path in the kernel, maintaining stability even under high load.

How Do You Install and Configure Tetragon on Production Linux Servers?

Deployment strategy depends entirely on whether you run bare-metal/VMs or Kubernetes. On a typical Ubuntu 22.04/24.04 server hosting Laravel or WordPress, I prefer the systemd service approach over Docker containers because Tetragon needs direct kernel access anyway. Running it inside Docker adds unnecessary abstraction layers for a tool that must touch the host kernel.

Bare Metal / VM Installation (Ubuntu/Debian)

For standalone servers, use the official APT repository to ensure you receive security patches automatically. As of 2026, Tetragon v1.4+ is the stable release supporting Linux kernels 5.15 through 6.8.

<!-- Add Cilium GPG key and repository -->
curl -fsSL https://deb.cilium.io/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/cilium-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/cilium-archive-keyring.gpg] https://deb.cilium.io stable main" | sudo tee /etc/apt/sources.list.d/cilium.list

<!-- Install Tetragon -->
sudo apt update
sudo apt install tetragon

<!-- Enable and start the service -->
sudo systemctl enable --now tetragon
sudo systemctl status tetragon

After installation, verify the eBPF programs are loaded correctly. The tetragon status command should show active probes. If you see "failed to load BPF program," check your kernel version with uname -r. Kernels older than 5.15 lack necessary BTF (BPF Type Format) support, requiring either a kernel upgrade or running Tetragon in compatibility mode with reduced functionality.

Kubernetes Deployment via Helm

In containerized environments, Tetragon runs as a DaemonSet. This is the preferred method for clusters running microservices or multi-tenant SaaS applications. The Helm chart handles RBAC, CRDs, and node selector configuration automatically.

helm repo add cilium https://helm.cilium.io/
helm repo update

helm install tetragon cilium/tetragon \
  --namespace kube-system \
  --set tetragon.enabled=true \
  --set export.stdout.enabled=false \
  --set export.aggregator.enabled=true

A common mistake I've seen in production is enabling stdout export in high-traffic clusters. This floods pod logs and consumes disk I/O. Always configure an external exporter (OpenTelemetry, Elasticsearch, or file rotation) for production workloads. For development or debugging, stdout is acceptable, but never leave it enabled on a busy eCommerce site processing hundreds of requests per second.

How Do You Write Effective TracingPolicies for Web Applications?

TracingPolicies are YAML manifests that define what Tetragon watches and how it responds. Unlike generic seccomp profiles that only allow/deny syscalls, TracingPolicies understand process context, file paths, and network destinations. This contextual awareness is what makes Tetragon: Runtime Security with eBPF practical for web developers rather than just kernel engineers.

Blocking Unauthorized Binary Execution

On a hardened web server, your PHP-FPM worker should never spawn a shell. Attackers exploiting RCE vulnerabilities in plugins or dependencies often attempt to execute /bin/bash, /bin/sh, or download scripts via wget/curl. This policy blocks shell execution specifically from the PHP-FPM process tree while allowing legitimate CLI commands during deployment.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: prevent-php-shell-execution
spec:
  kprobes:
    - call: "sys_execve"
      syscall: true
      selectors:
        - matchPIDs:
            - operator: In
              values:
                - 1  # init/systemd
          matchActions:
            - action: Sigkill
              kernelReturn: false
        - matchBinaries:
            - path: "/usr/sbin/php-fpm*"
              operator: Prefix
          matchActions:
            - action: Log
              kernelReturn: false
            - action: Override
              overrideAction:
                returnCode: -1  # EPERM
              kernelReturn: true
  options:
    - name: "policy-name"
      value: "prevent-php-shell-execution"

This policy uses two selectors. The first allows PID 1 (systemd) to execute anything unrestricted. The second targets php-fpm binaries specifically, logging attempts and returning EPERM to block execution. The kernelReturn: true flag is critical — without it, Tetragon logs the event but doesn't actually prevent the syscall.

Monitoring Sensitive File Access

Legal-tech portals handling client documents require strict file access auditing. This policy tracks reads to sensitive directories and alerts when unexpected processes access them. Unlike auditd, Tetragon captures the full process ancestry, so you can distinguish between a legitimate backup job and a compromised web worker reading the same files.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-sensitive-documents
spec:
  kprobes:
    - call: "sys_openat"
      syscall: true
      selectors:
        - matchPaths:
            - path: "/var/www/legal-portal/storage/documents/"
              operator: Prefix
          matchActions:
            - action: Log
              kernelReturn: false
  lsm:
    - hook: "file_open"
      selectors:
        - matchPaths:
            - path: "/etc/shadow"
              operator: Equal
          matchActions:
            - action: Sigkill
              kernelReturn: false

Note the dual approach: kprobes for broad monitoring with low overhead, LSM (Linux Security Module) hooks for hard enforcement on critical system files. LSM hooks are more restrictive but require kernel 5.7+ with CONFIG_BPF_LSM enabled. Always test LSM policies in log-only mode first; a misconfigured file_open hook can lock you out of SSH.

How Does Tetragon Compare to Falco, Auditd, and Seccomp?

Choosing the right runtime security tool requires understanding trade-offs. I've deployed all four in various client environments, and each serves different purposes. Tetragon isn't always the answer — sometimes simpler tools suffice. This comparison reflects real production usage on Ubuntu 22.04/24.04 servers running PHP/Laravel workloads in 2026.

When to choose Tetragon: You need to actively block attacks, not just detect them. You want unified observability and enforcement in one tool. Your workload is latency-sensitive (eCommerce, APIs) and can't tolerate auditd overhead.

When to stick with Falco: Your primary goal is threat detection and SOC integration. You have existing Falco rulesets and don't need blocking. You're running older kernels without LSM BPF support.

When auditd still wins: Regulatory compliance (PCI-DSS, HIPAA) explicitly requires audit subsystem logs. You need guaranteed logging regardless of eBPF availability. Forensic investigation where completeness matters more than performance.

When seccomp is sufficient: You're hardening immutable containers with known syscall sets. You don't need runtime flexibility or context-aware decisions. Performance is absolutely critical and you've profiled the exact syscall surface.

What Are Common Production Pitfalls When Deploying Tetragon?

I've debugged enough Tetragon deployments to know where things break. These aren't theoretical concerns — they're issues I've encountered on live systems serving real traffic. Avoiding them saves hours of 3 AM troubleshooting.

• Missing BTF support: Tetragon requires BTF (BPF Type Format) for advanced features. Run ls /sys/kernel/btf/vmlinux to verify. If missing, install linux-image-generic with BTF or compile your kernel with CONFIG_DEBUG_INFO_BTF=y. Without BTF, Tetragon falls back to limited kprobe-only mode, losing LSM enforcement and some context.
• Overly broad selectors: A policy matching path: "/" with Prefix operator will trigger on every single file operation system-wide. This kills performance and generates terabytes of logs. Always scope to specific binaries, paths, or PIDs. Test with tetragon policy trace before deploying to production.
• Ignoring kernel version mismatches: eBPF features vary significantly between kernel versions. A policy using bprm_check_security LSM hook works on 5.15+ but fails silently on 5.4. Document your minimum kernel requirement and validate during CI/CD, not at deploy time.
• Forgetting cgroup v2 requirements: Container-aware features require cgroup v2. Check with stat -fc %T /sys/fs/cgroup/ — it should return "cgroup2fs". If you're on cgroup v1, Tetragon can't correlate events to containers accurately. Migrate to cgroup v2 or accept reduced container visibility.
• Log rotation misconfiguration: Tetragon's JSON output grows fast. Default journald limits may drop events. Configure explicit log rotation in /etc/tetragon/tetragon.yaml with max file size and retention count. For high-volume systems, ship directly to OpenTelemetry Collector rather than writing to local disk.

One subtle issue worth highlighting: Tetragon policies are eventually consistent. When you apply a new policy via tetragon policy apply, there's a brief window (milliseconds to seconds depending on load) where the old policy still applies. For zero-downtime deployments, maintain backward-compatible policies during transitions. Never delete and recreate policies atomically — update them in place using versioned names.

Another gotcha involves namespace isolation in Kubernetes. By default, Tetragon policies apply cluster-wide. If you're running multi-tenant SaaS applications (like those discussed in multi-tenant Laravel architectures), scope policies to specific namespaces using matchNamespaces selectors. Otherwise, a policy intended for tenant A might inadvertently block legitimate operations in tenant B's pods.

Implementing Tetragon: Runtime Security with eBPF in Your Stack

Tetragon represents a fundamental shift from reactive security monitoring to proactive kernel-level enforcement. For teams running PHP/Laravel applications, WordPress sites, or microservices on Linux, it closes the gap between application-layer WAFs and traditional host-based IDS. The key to successful adoption is starting small: deploy in log-only mode, validate against your actual workload patterns, then gradually enable enforcement for high-confidence rules.

Don't try to replace all your security tooling at once. Tetragon complements existing WAFs, vulnerability scanners, and compliance auditors — it doesn't substitute for them. Use it specifically for the attack vectors those tools miss: runtime exploitation, privilege escalation, and unauthorized binary execution. Pair it with solid current cybersecurity practices and regular dependency updates for comprehensive coverage.

If you're managing infrastructure for Nepal-based clients or global SaaS platforms and need help designing a runtime security strategy that balances protection with performance, reach out to discuss your specific architecture. Proper eBPF security requires understanding both your application's legitimate behavior patterns and your threat model — generic policies rarely survive contact with production traffic.