Kubernetes Runtime Security: Bedrohungen in Echtzeit erkennen und stoppen

TL;DR

• Runtime Security schliesst die Luecke zwischen Image-Scanning (vor Deployment) und Incident Response (nach einem Breach). Sie erkennt Angriffe waehrend der Ausfuehrung.
• Falco ist der etablierte Standard (CNCF Graduated), arbeitet regelbasiert und erkennt verdaechtige Syscalls, Dateizugriffe und Netzwerkaktivitaeten.
• Tetragon (eBPF-basiert, von Cilium/Isovalent) kann nicht nur erkennen, sondern Prozesse direkt im Kernel blockieren -- ohne Sidecar und ohne Userspace-Overhead.
• Die groesste Herausforderung in der Praxis ist nicht die Installation, sondern das Regel-Tuning: Zu viele False Positives fuehren zu Alert Fatigue.
• Starten Sie mit einem Namespace, tunen Sie die Regeln zwei Wochen lang, und rollen Sie erst dann auf den gesamten Cluster aus.

Warum Image-Scanning allein nicht reicht

Container-Image-Scanning mit Trivy oder Grype ist wichtig, deckt aber nur bekannte CVEs in den Image-Layern ab. Es erkennt nicht:

• Zero-Day-Exploits, die zur Laufzeit ausgenutzt werden
• Kompromittierte Supply-Chain-Abhaengigkeiten, die erst bei Ausfuehrung schadhaft werden
• Legitime Binaries, die fuer boeswillige Zwecke missbraucht werden (Living-off-the-Land)
• Laterale Bewegungen eines Angreifers innerhalb des Clusters
• Container Escapes auf den Host

Runtime Security ueberwacht das tatsaechliche Verhalten von Prozessen in laufenden Containern. Wenn ein Nginx-Container ploetzlich eine Shell startet oder ein Python-Prozess auf /etc/shadow zugreift, ist das verdaechtig -- unabhaengig davon, ob das Image bekannte CVEs hat.

Tool-Vergleich: Falco vs. Tetragon vs. KubeArmor

Alle drei Tools adressieren Runtime Security, unterscheiden sich aber fundamental in Architektur und Faehigkeiten.

Wann welches Tool?

• Falco ist die richtige Wahl, wenn Sie primaer Visibilitaet und Alerting brauchen. Es hat das groesste Regelwerk und die meisten Integrationen (SIEM, Slack, PagerDuty).
• Tetragon ist ideal, wenn Sie Angriffe nicht nur erkennen, sondern direkt im Kernel blockieren wollen -- ohne den Umweg ueber einen Userspace-Agenten.
• KubeArmor ist spezialisiert auf Policy Enforcement und eignet sich gut als Ergaenzung zu einem Detection-Tool.

In der Praxis sieht man haeufig die Kombination Falco (Detection) + Tetragon oder KubeArmor (Enforcement).

Falco: Setup und Regelbeispiele

Installation als DaemonSet via Helm

# Falco Helm Repository hinzufuegen
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Falco mit eBPF-Probe installieren (kein Kernel-Modul noetig)
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set falco.grpc.enabled=true \
  --set falco.grpc_output.enabled=true \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/XXX"

Falcosidekick leitet Alerts an verschiedene Ziele weiter: Slack, MS Teams, Elasticsearch, Prometheus AlertManager und viele mehr.

Praxis-Regeln: Was Sie als erstes erkennen sollten

# Regel 1: Shell in einem non-shell Container
- rule: Shell in Container
  desc: >
    Ein Shell-Prozess wurde in einem Container gestartet,
    der normalerweise keine Shell ausfuehren sollte.
  condition: >
    spawned_process
    and container
    and proc.name in (bash, sh, zsh, csh, dash)
    and not container.image.repository in (
      my-debug-image, toolbox
    )
  output: >
    Shell gestartet in Container
    (user=%user.name pod=%k8s.pod.name ns=%k8s.ns.name
    image=%container.image.repository cmd=%proc.cmdline)
  priority: WARNING
  tags: [shell, container, mitre_execution]

# Regel 2: Zugriff auf sensitive Dateien
- rule: Read Sensitive File in Container
  desc: >
    Ein Prozess liest eine sensitive Datei wie
    /etc/shadow oder /etc/kubernetes/pki/*.
  condition: >
    open_read
    and container
    and (fd.name startswith /etc/shadow
      or fd.name startswith /etc/kubernetes/pki
      or fd.name startswith /var/run/secrets)
    and not proc.name in (kubelet, kube-proxy)
  output: >
    Sensitive Datei gelesen
    (user=%user.name file=%fd.name pod=%k8s.pod.name
    ns=%k8s.ns.name proc=%proc.name)
  priority: CRITICAL
  tags: [filesystem, sensitive, mitre_credential_access]

# Regel 3: Unerwartete ausgehende Verbindung
- rule: Unexpected Outbound Connection
  desc: >
    Ein Container baut eine Verbindung zu einer
    externen IP auf, die nicht erwartet wird.
  condition: >
    outbound
    and container
    and not fd.sip in (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
    and not k8s.ns.name in (kube-system, monitoring)
  output: >
    Ausgehende Verbindung zu externer IP
    (pod=%k8s.pod.name ns=%k8s.ns.name ip=%fd.sip port=%fd.sport
    proc=%proc.name)
  priority: NOTICE
  tags: [network, outbound, mitre_exfiltration]

Alert-Ausgabe und Integration

Falco gibt Alerts als strukturierte Events aus. Ein typischer Alert sieht so aus:

2026-02-10T14:23:45.123Z WARNING Shell gestartet in Container
  (user=root pod=api-gateway-7d8f9 ns=production
   image=api-gateway cmd=bash)

Ueber Falcosidekick koennen Sie diese Events an Ihr SIEM (Elasticsearch, Splunk), Ihren Chat (Slack, Teams) oder Ihren Alerting-Stack (Prometheus AlertManager, PagerDuty) weiterleiten.

Tetragon: Enforcement direkt im Kernel

Tetragon geht einen Schritt weiter als Falco. Statt nur zu alarmieren, kann Tetragon Prozesse direkt im Kernel blockieren oder killen -- bevor sie Schaden anrichten. Das ist moeglich, weil Tetragon eBPF-Programme direkt an Kernel-Hooks (kprobes, tracepoints, LSM hooks) anbindet.

TracingPolicy Beispiel

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-privilege-escalation
spec:
  kprobes:
  - call: "__x64_sys_setuid"
    syscall: true
    args:
    - index: 0
      type: int
    selectors:
    - matchArgs:
      - index: 0
        operator: Equal
        values:
        - "0"
      matchActions:
      - action: Sigkill
      matchNamespaces:
      - namespace: production
        operator: In

Diese Policy killt jeden Prozess im Namespace production, der versucht, seine UID auf 0 (root) zu setzen. Das passiert direkt im Kernel, ohne Userspace-Verzoegerung.

Der Vorteil gegenueber Falco: Die Reaktionszeit liegt im Mikrosekundenbereich statt im Millisekundenbereich. Der Nachteil: Fehlkonfigurierte Enforcement-Policies koennen legitime Prozesse abwuergen. Deshalb ist ein Audit-Modus (nur loggen, nicht blockieren) vor dem Enforcement-Modus unverzichtbar.

Praxis-Empfehlung: Schrittweise einfuehren

Phase 1: Visibilitaet (Woche 1-4)

Installieren Sie Falco auf einem nicht-produktiven Cluster oder einem einzelnen Namespace. Nutzen Sie die Default-Regeln und beobachten Sie die Alerts. Ziel dieser Phase ist nicht Sicherheit, sondern Verstaendnis: Welches Verhalten ist normal fuer Ihre Workloads?

Typische Learnings in Phase 1:

• Init-Container loesen Shell-Alerts aus -- das ist erwartetes Verhalten
• Health-Check-Prozesse lesen Dateien, die als sensitiv klassifiziert sind
• CronJobs erzeugen Netzwerk-Alerts zu ungewoehnlichen Zeiten

Dokumentieren Sie diese Erkenntnisse. Sie bilden die Grundlage fuer das Regel-Tuning.

Phase 2: Tuning (Woche 5-8)

Passen Sie die Regeln an Ihre Umgebung an. Erstellen Sie Ausnahmen fuer bekanntes, legitimes Verhalten. Erhoehen Sie die Prioritaet fuer Alerts, die tatsaechlich auf Bedrohungen hinweisen.

Das Ziel: Die Anzahl der Alerts pro Tag auf ein Level reduzieren, das Ihr Team tatsaechlich bearbeiten kann. 10-20 relevante Alerts pro Tag sind handhabbar. 500 Alerts pro Tag fuehren zu Alert Fatigue -- und dann wird auch der eine echte Angriff uebersehen.

Phase 3: Production Rollout (Woche 9-12)

Rollen Sie Falco auf alle produktiven Namespaces aus. Integrieren Sie die Alerts in Ihre bestehenden Incident-Response-Prozesse. Definieren Sie Eskalationspfade: Wer reagiert auf einen CRITICAL-Alert um 3 Uhr nachts?

Optional in dieser Phase: Tetragon fuer Enforcement in den kritischsten Namespaces einsetzen -- aber nur nach ausfuehrlichem Audit-Modus.

Ressourcen-Overhead: Was Runtime Security wirklich kostet

Eine berechtigte Sorge: Wie viel Performance kostet Runtime Security?

Der Overhead ist in den meisten Szenarien vernachlaessigbar. Bei sehr I/O-intensiven Workloads (Datenbanken mit hohem Durchsatz) sollten Sie den Impact im Staging testen. Aber in der Regel ist der Overhead kleiner als der eines Service Mesh Sidecars.

Integration mit dem restlichen Security-Stack

Runtime Security ist am wirksamsten, wenn sie in den bestehenden Security-Stack integriert ist:

Monitoring: Falco-Metriken nach Prometheus exportieren und Grafana-Dashboards bauen. So sehen Sie Trends: Steigt die Anzahl der Alerts? Gibt es neue Muster? Mehr zu Monitoring-Architektur in unserem Kubernetes Monitoring Guide.

Network Policies: Runtime Security erkennt verdaechtige Netzwerkverbindungen. Die Remediation erfolgt ueber Network Policies, die den Traffic einschraenken.

Penetration Testing: Ein regelmae ssiger Pen-Test prueft, ob Ihre Runtime-Security-Regeln tatsaechlich greifen. Kann ein Pen-Tester eine Shell starten, ohne dass ein Alert ausgeloest wird? Dann stimmt etwas mit den Regeln nicht.

Verschluesselung: Runtime Security erkennt Zugriffe auf Secrets und Schluessel. Die Verschluesselungsstrategie stellt sicher, dass selbst bei erfolgreichem Zugriff die Daten geschuetzt bleiben.

DSGVO und Compliance

Runtime Security adressiert mehrere Anforderungen aus Art. 32 DSGVO:

• Integritaet der Verarbeitungssysteme: Echtzeit-Erkennung von Manipulationen an Containern und Prozessen
• Belastbarkeit: Schnellere Erkennung und Eindaemmung von Angriffen erhoehen die Systemresilienz
• Verfahren zur Ueberpruefung: Die Audit-Logs von Falco/Tetragon dienen als Nachweis fuer implementierte Schutzmassnahmen
• Wiederherstellung: Fruehzeitige Erkennung reduziert den Blast Radius und verkuerzt die Recovery-Zeit

Die detaillierten Audit-Logs koennen auch als Nachweis bei BSI-Pruefungen oder ISO-27001-Zertifizierungen herangezogen werden.

Haeufige Fehler

Default-Regeln ohne Tuning in Produktion ausrollen. Das fuehrt zu Hunderten von False Positives pro Stunde. Investieren Sie mindestens zwei Wochen in das Regel-Tuning.

Falco als DaemonSet ohne Ressourcen-Limits deployen. Unter Last kann der Falco-Agent CPU und Memory beanspruchen. Setzen Sie immer Requests und Limits.

Alerts in einen Slack-Channel schicken und hoffen, dass jemand reagiert. Ohne definierte Eskalationspfade und Verantwortlichkeiten werden Alerts ignoriert. Integrieren Sie Alerts in Ihr Incident-Management-System.

Enforcement-Policies ohne Audit-Phase aktivieren. Eine falsch konfigurierte Tetragon-Policy kann legitime Prozesse killen und damit einen Ausfall verursachen. Immer erst im Audit-Modus testen.

Wenn Sie Runtime Security in Ihrem Kubernetes-Cluster einfuehren moechten und Unterstuetzung bei der Tool-Auswahl, dem Setup oder dem Regel-Tuning benoetigen, stehen wir Ihnen zur Verfuegung. Melden Sie sich unter /kontakt fuer ein technisches Erstgespraech.