Falco: Runtime Security für Kubernetes-Cluster

TL;DR

Falco überwacht Syscalls in Kubernetes-Containern und erkennt verdächtiges Verhalten zur Laufzeit - etwa Shell-Zugriffe, Dateizugriffe auf sensible Pfade oder Netzwerkverbindungen. Die Installation erfolgt per Helm, eigene Regeln lassen sich als YAML definieren. Alerting an Slack oder PagerDuty ist über Falcosidekick möglich.

Falco installieren

Falco lässt sich am einfachsten via Helm deployen. Der eBPF-Treiber ist die empfohlene Variante für verwaltete Kubernetes-Cluster:

# Helm Repo hinzufügen
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Falco mit eBPF-Treiber installieren
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=modern_ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

# Pods prüfen
kubectl get pods -n falco

Nach wenigen Sekunden läuft Falco als DaemonSet auf jedem Node und überwacht alle Syscalls.

Was Falco out-of-the-box erkennt

Falco bringt über 100 vordefinierte Regeln mit. Die wichtigsten Kategorien:

Custom Rules erstellen

Die vordefinierten Regeln decken Standardfälle ab. Für produktive Umgebungen brauchen Sie eigene Regeln. Falco-Regeln bestehen aus drei Elementen: macro, list und rule.

Shell in Container erkennen

- rule: Shell in Production Container
  desc: Erkennt Shell-Zugriffe in Production-Containern
  condition: >
    spawned_process
    and container
    and proc.name in (bash, sh, zsh, csh)
    and k8s.ns.name = "production"
  output: >
    Shell gestartet in Production-Container
    (user=%user.name container=%container.name
    namespace=%k8s.ns.name pod=%k8s.pod.name
    command=%proc.cmdline image=%container.image.repository)
  priority: WARNING
  tags: [security, shell]

Zugriff auf sensible Dateien

- list: sensitive_paths
  items: [/etc/shadow, /etc/kubernetes/admin.conf,
          /var/run/secrets/kubernetes.io/serviceaccount/token]

- rule: Sensitive File Access
  desc: Zugriff auf sensible Dateien im Container
  condition: >
    open_read
    and container
    and fd.name in (sensitive_paths)
  output: >
    Sensible Datei gelesen (file=%fd.name user=%user.name
    container=%container.name pod=%k8s.pod.name)
  priority: CRITICAL
  tags: [security, filesystem]

Regeln als ConfigMap deployen

# Custom Rules als values.yaml
cat <<'EOF' > falco-custom-values.yaml
customRules:
  custom-rules.yaml: |-
    - rule: Crypto Mining Detection
      desc: Erkennt Verbindungen zu Mining-Pools
      condition: >
        evt.type = connect
        and container
        and fd.sport in (3333, 4444, 8333)
      output: >
        Möglicher Crypto-Mining-Versuch
        (container=%container.name connection=%fd.name)
      priority: CRITICAL
      tags: [security, crypto]
EOF

# Helm Upgrade mit Custom Rules
helm upgrade falco falcosecurity/falco \
  --namespace falco \
  -f falco-custom-values.yaml

Alerting einrichten

Falcosidekick leitet Falco-Events an externe Systeme weiter. Die Konfiguration erfolgt über Helm Values:

# falcosidekick-values.yaml
falcosidekick:
  enabled: true
  config:
    slack:
      webhookurl: "https://hooks.slack.com/services/T00/B00/xxx"
      channel: "#security-alerts"
      minimumpriority: "warning"
    pagerduty:
      routingkey: "your-pagerduty-key"
      minimumpriority: "critical"

Falcosidekick unterstützt über 60 Ausgabekanäle: Slack, PagerDuty, Elasticsearch, Loki, AWS Security Hub und viele mehr.

Falco vs. Tetragon

Beide Tools überwachen Container zur Laufzeit, unterscheiden sich aber im Ansatz:

Empfehlung: Falco für den Einstieg in Runtime Security. Tetragon, wenn Sie zusätzlich Enforcement (aktives Blockieren) benötigen oder bereits Cilium als CNI nutzen.

Falco in Production betreiben

Drei Tipps für den produktiven Einsatz:

Tuning ist Pflicht. Die Standardregeln erzeugen viele False Positives. Starten Sie im Alert-Only-Modus und erstellen Sie Ausnahmen für bekannte Prozesse:

- rule: Terminal shell in container
  append: true
  condition: and not (k8s.ns.name = "debug-tools")

Ressourcen begrenzen. Falco kann CPU-intensiv sein. Setzen Sie Limits im Helm Chart:

resources:
  requests:
    cpu: 100m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

Log-Aggregation nutzen. Leiten Sie Falco-Events an Ihr zentrales Logging weiter (Loki, Elasticsearch), um Trends zu erkennen und Incidents zu korrelieren.

FAQ

Braucht Falco Root-Rechte auf den Nodes?

Ja, Falco benötigt privilegierten Zugriff, um Syscalls zu überwachen. Mit dem modernen eBPF-Treiber sind die Anforderungen geringer als beim Kernel-Modul.

Wie hoch ist der Performance-Overhead von Falco?

Der eBPF-Treiber verursacht typischerweise 1-3% CPU-Overhead. Bei sehr hohem Syscall-Volumen kann es mehr sein - testen Sie in Ihrer Umgebung.

Kann Falco Angriffe auch blockieren?

Nein, Falco ist ein reines Detection-Tool. Für aktives Blocking kombinieren Sie Falco mit Tetragon oder nutzen Sie Falco Talon für automatisierte Response-Aktionen.

Funktioniert Falco mit verwalteten Kubernetes-Diensten wie EKS/GKE/AKS?

Ja, mit dem eBPF-Treiber funktioniert Falco auf allen verwalteten Plattformen. Der Kernel-Modul-Treiber wird dort oft nicht unterstützt.

Wie aktualisiere ich die Falco-Regeln?

Die Community-Regeln werden über das Helm Chart aktualisiert. Eigene Regeln pflegen Sie in Ihrer Values-Datei und deployen sie per helm upgrade.