Falco vs. Tetragon: Runtime Security für Kubernetes

Kubernetes-Cluster sind nach außen oft gut abgesichert — aber was passiert, wenn ein Angreifer bereits im Cluster ist? Runtime Security überwacht laufende Container auf verdächtiges Verhalten und blockiert Angriffe in Echtzeit. Die beiden führenden Open-Source-Tools sind Falco (CNCF) und Tetragon (Cilium/Isovalent). Dieser Vergleich zeigt die wichtigsten Unterschiede.

Was ist Falco?

Falco ist ein CNCF-Graduated-Projekt und der De-facto-Standard für Kubernetes Runtime Security. Es überwacht Linux-Syscalls (Systemaufrufe) via eBPF oder Kernel-Module und löst Alerts aus, wenn definierte Regeln greifen — z.B. wenn ein Container eine Shell öffnet, sensitive Dateien liest oder Netzwerkverbindungen nach außen aufbaut.

Falco-Architektur:

  • Sensor: Kernel-eBPF-Programm oder Kernel-Modul, fängt Syscalls ab
  • Engine: Evaluiert Events gegen Falco-Regeln (YAML-basiert)
  • Outputs: stdout, syslog, HTTP-Webhook, Kafka, Slack, PagerDuty
  • Falco Sidekick: Optionaler Event-Router für komplexe Alerting-Setups
# Beispiel Falco-Regel: Shell in Container erkennen
- rule: Terminal shell in container
  desc: >
    A shell was spawned inside a container with interactive terminal.
    This is often used by attackers for lateral movement.
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container.image.repository != "your-debug-image"
  output: >
    Shell spawned in container (user=%user.name container=%container.name
    image=%container.image.repository shell=%proc.name parent=%proc.pname
    cmdline=%proc.cmdline)
  priority: WARNING
  tags: [container, shell, mitre_execution]

Was ist Tetragon?

Tetragon ist ein eBPF-basiertes Security-Observability- und Runtime-Enforcement-Tool, ursprünglich von Isovalent (heute Cilium-Projekt, CNCF) entwickelt. Im Gegensatz zu Falco, das nur Alerts auslöst, kann Tetragon Prozesse direkt in-kernel blockieren — bevor ein Syscall ausgeführt wird. Das macht Tetragon zu einem "Prevention"-Tool statt reinem "Detection"-Tool.

Tetragon-Architektur:

  • TracingPolicy: Kubernetes CRD zur Definition von eBPF-Programmen
  • In-Kernel Enforcement: Blockiert Syscalls direkt im eBPF-Programm
  • Cilium Integration: Kombiniert Network Policy + Runtime Security
  • Observability: Detaillierter Process-Tree und Netzwerk-Events
# Beispiel TracingPolicy: Schreibzugriff auf /etc blockieren
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-writes-to-etc
spec:
  kprobes:
    - call: "sys_openat"
      syscall: true
      args:
        - index: 1
          type: "string"
      selectors:
        - matchArgs:
            - index: 1
              operator: "Prefix"
              values:
                - "/etc/"
          matchActions:
            - action: Sigkill

Direkter Vergleich

Kriterium Falco Tetragon
Ansatz Detection (Alerting) Prevention + Detection
eBPF Ja (oder Kernel-Modul) Ja (ausschließlich)
In-Kernel Blocking Nein Ja (Sigkill, Override)
Kubernetes Native Operator verfügbar CRDs (TracingPolicy)
Regel-Sprache Falco Rules (YAML) Go + YAML (TracingPolicy)
CNCF Status Graduated Incubating (via Cilium)
Cilium Abhängigkeit Nein Optional (aber empfohlen)
Community Sehr groß Wächst stark
Lernkurve Mittel Steil

Falco: Stärken und Schwächen

Stärken:

  • Riesige Community und viele fertige Regel-Sets (CNCF, CIS, MITRE ATT&CK)
  • Flexibles Alerting-Ökosystem (Falco Sidekick + 50+ Integrationen)
  • Keine Abhängigkeit von spezifischem CNI-Plugin
  • Große Anzahl fertiger Helm-Charts und Operator-Integrationen
  • Bewährt in Production bei tausenden Unternehmen

Schwächen:

  • Nur Detection, kein Prevention (Angriff wird erkannt, aber nicht gestoppt)
  • Performance-Overhead durch Syscall-Monitoring
  • Kernel-Modul als Alternative zu eBPF ist weniger sicher

Tetragon: Stärken und Schwächen

Stärken:

  • In-Kernel Blocking: Angriff wird gestoppt, bevor der Syscall ausgeführt wird
  • Sehr detaillierter Process-Tree inkl. Kubernetes-Kontext
  • Native Cilium-Integration für kombinierte Network + Runtime Security
  • Niedrige Latenz durch eBPF-Execution im Kernel

Schwächen:

  • Steilere Lernkurve (eBPF-Kenntnisse hilfreich)
  • Kleinere Community und weniger fertige Policies
  • Beste Nutzung nur mit Cilium als CNI
  • TracingPolicy-Fehler können System destabilisieren

Integration mit bestehenden Tools

Falco lässt sich nahtlos mit Prometheus, Grafana und Loki integrieren:

# Falco mit Helm installieren
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl=https://hooks.slack.com/services/XXX

# Tetragon mit Helm installieren
helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon \
  --namespace kube-system

Wann Falco wählen?

Falco ist die richtige Wahl für:

  • Bestehende Cluster unabhängig vom verwendeten CNI (Calico, Flannel, Weave)
  • Teams, die Alerting und SIEM-Integration priorisieren (Splunk, ELK, Datadog)
  • Compliance-Szenarien, wo fertige MITRE ATT&CK oder CIS-Regelsets benötigt werden
  • Einstieg in Runtime Security — breite Community, viele Tutorials

Wann Tetragon wählen?

Tetragon ist ideal für:

  • Cilium-basierte Cluster, die eine vollständige Zero-Trust-Architektur aufbauen
  • Hochsicherheits-Umgebungen, wo Detection allein nicht ausreicht
  • Teams mit eBPF-Kenntnissen, die maximale Kontrolle über Kernel-Events brauchen
  • Prevention-First-Ansatz: Lieber Prozess beenden als Alert ignorieren

Kombination: Falco + Tetragon

Viele Production-Teams setzen beide Tools parallel ein: Tetragon für In-Kernel-Prevention kritischer Syscalls (z.B. /etc-Schreibzugriffe, Privilege Escalation), Falco für breitflächiges Alerting und SIEM-Integration. Da beide eBPF nutzen, ist der kombinierte Overhead managebar.

Fazit

Falco ist der klare Gewinner für Einsteiger und Teams, die Runtime Security schnell und breit aufstellen wollen. Die große Community, fertige Regelsets und das flexible Alerting-Ökosystem machen es zur pragmatischen Wahl für die meisten Kubernetes-Cluster.

Tetragon überzeugt in Hochsicherheits-Umgebungen, besonders in Kombination mit Cilium. Die Fähigkeit, Angriffe direkt im Kernel zu blockieren, hebt es über klassische SIEM-basierte Ansätze hinaus.

Weiterführende Artikel

Verwandte Technologien im Techradar