eBPF-Monitoring im Kubernetes: Detektion unsichtbarer Runtime-Threats

9 Min. Lesezeit

Angreifer waren 2025 in deutschen Kubernetes-Clustern länger drin als der Median der DACH-CISOs noch wahrhaben will. Sysdig hat in seinem Threat-Report 2026 dokumentiert, dass die durchschnittliche Aufenthaltszeit eines Container-Intruders 196 Stunden beträgt, der M-Trends-Report von Mandiant kommt auf 21 Tage. Die Lücke zwischen Cluster-Realität und EDR-Sichtfeld ist breit, und sie ist strukturell. Klassische Endpoint-Detection arbeitet auf Host-Ebene und sieht in einem Container die meisten relevanten Aktivitäten gar nicht. Mit eBPF und den darauf aufgesetzten Open-Source-Tools Falco und Tetragon schließt sich diese Lücke 2026 in der Breite. Black Hat USA 2026 hat eBPF zum offiziellen Track erhoben, was den Detection-Engineering-Markt für die nächsten zwölf Monate prägt.

Das Wichtigste in Kürze

• EDR hat in Kubernetes konstruktive Lücken: Container-Runtime-Aktivitäten, in-memory Code-Execution, ephemere Workloads und Sidecar-Pattern entgehen klassischer Host-EDR. eBPF schaut auf Kernel-Syscall-Ebene und schließt diese Sichtlücke.
• Falco und Tetragon sind 2026 produktionsreif: Falco liefert breite Rule-Bibliothek und gute Operator-Integration, Tetragon stärker bei Process-Genealogy und Network-Observability. Die zwei Tools sind komplementär, nicht konkurrierend.
• Angreifer nutzen eBPF selbst: Stealth-Loader, in-memory Rootkits und Syscall-Manipulationen über eBPF-Programme nehmen 2026 sichtbar zu. Detection muss Kernel-Telemetry mitlesen, sonst sind Container-Hosts geblendet.

VerwandtDetection-Engineering ohne Vendor-Lock  /  Selbst-Replikation: KI-Agenten

Warum klassische EDR im Cluster nicht reicht

Endpoint-Detection-and-Response wurde für klassische Server- und Workstation-Setups entworfen. Ein EDR-Agent läuft auf dem Host, beobachtet Prozess-Genealogie, Datei-Operationen, Netzwerk-Verbindungen und antwortet auf vordefinierte Anomalien. In einer Kubernetes-Umgebung kippt dieses Modell aus drei Gründen.

Erstens: Container sind ephemer. Ein Pod, der nur 90 Sekunden lebt, hinterlässt im Host-EDR bestenfalls eine Spur, die durch das Telemetrie-Sampling fällt. Die Detection-Logik geht von minutenlangen Prozessen aus, die Realität sind Sekunden. Wer Container-Workloads mit Host-Granularität beobachtet, sieht 70 bis 80 Prozent der relevanten Events nicht.

Zweitens: In-memory Execution. Moderne Angreifer-Toolchains für Container nutzen Memory-only Loader, die nie ein File auf Disk legen. Klassische EDR-Detection, die auf File-System-Events aufbaut, ist hier konzeptuell blind. eBPF dagegen sieht die zugrundeliegenden Syscalls, weil sie zwingend durch den Kernel laufen.

Drittens: Sidecar- und Service-Mesh-Architekturen. Wenn ein einziger Pod fünf Container und sieben Netzwerk-Verbindungen unterhält, die intern über mTLS laufen, sieht ein Host-EDR vor allem unklare Netzwerk-Pakete. Die semantische Ebene fehlt. eBPF kann diese Telemetrie auf Workload-Ebene anreichern, weil sie aus dem Kernel kommt, bevor mTLS greift.

Wie Falco und Tetragon konkret arbeiten

Beide Tools setzen auf eBPF, unterscheiden sich aber in Schwerpunkt und Reifegrad. Falco ist das ältere Projekt, CNCF-Graduated, liefert eine etablierte Regel-Bibliothek und integriert sauber mit Prometheus, Loki und SIEM-Pipelines. Die Stärke liegt in Breite und Reife: eine Falco-Standardregelmenge fängt schon im Erstwurf zwischen 60 und 80 Prozent der MITRE-ATT&CK-for-Container-Techniken.

Tetragon kommt aus dem Cilium-Ökosystem, ist deutlich enger mit der Cilium-CNI verzahnt und bringt zwei Eigenschaften, die Falco nicht in dieser Tiefe liefert: erstens eine vollständige Process-Genealogy, also den Vater-Sohn-Stammbaum jeder Container-Aktivität, zweitens eine Echtzeit-Enforcement-Schicht. Tetragon kann nicht nur erkennen, dass ein Prozess ein verbotenes Syscall ruft, sondern den Aufruf direkt im Kernel blockieren.

Für 2026 sieht der pragmatische Stack bei größeren DACH-Cluster-Betreibern oft so aus: Falco als breit aufgestellter Detector mit Rule-Library und SIEM-Integration, Tetragon ergänzend für Process-Genealogy in besonders sensiblen Namespaces und für selektives Runtime-Enforcement. Wer 2026 nur eins von beiden einsetzen will, beginnt mit Falco, weil die Lernkurve flacher und die Operator-Integration weiter ist.

Konkrete Detection-Beispiele für in-memory Threats

Drei Beispiel-Pattern, die 2026 in DACH-Clustern messbar zugenommen haben und die mit eBPF-Telemetrie greifbar werden.

Memfd-Loader und fileless Execution. Angreifer erzeugen einen anonymen Memory-File-Descriptor über memfd_create, schreiben Code hinein und executen ihn ohne Disk-Spuren. Falco-Regel pattern: alert bei memfd_create gefolgt von execveat innerhalb derselben Process-Gruppe in einem produktiven Namespace. Host-EDR sieht hier kein File, eBPF sieht die zwei Syscalls.

Container-Escape über cap_sys_admin Privilege-Escalation. Klassisches Escape-Pattern, das in 2025/2026 wieder häufiger in Honeypot-Logs auftaucht. Tetragon-Tracing-Policy alert bei Capability-Change innerhalb eines Containers, der nicht im Privileged-Namespace startet. Host-EDR sieht den Container nur als generischen Prozess des Container-Runtime, die Privilege-Verschiebung bleibt unsichtbar.

eBPF-basierte Rootkits. Angreifer laden eigene eBPF-Programme, die Syscalls patchen und Aktivität vor klassischen Tools verbergen. Falco-Plugin ebpf-program-loaded alert bei bpf_prog_load in einem nicht freigegebenen Namespace. Hier hilft nur Telemetry aus dem Kernel selbst, weil die User-Space-Sicht durch das Rootkit manipuliert ist.

Pros und Cons der zwei Tools

Wie ein realistischer Rollout 2026 aussieht

Wichtig ist, den Rollout nicht als Tool-Einführung, sondern als Detection-Engineering-Programm zu fahren. Eine eBPF-basierte Pipeline ohne dokumentierte Regeln, ohne CI-Tests für die Detection-Logik und ohne Alert-Triage-Routine in den SOC-Schichten produziert Daten ohne Wirkung. Wer Falco und Tetragon ernsthaft einsetzen will, plant 2026 mit zwei bis drei FTE Detection-Engineering, die nicht durch das normale SOC-Tagesgeschäft absorbiert werden.

Wo die Disziplin 2026 noch wackelt

Drei offene Punkte begleiten den eBPF-Trend 2026 und sollten in jedem Konzept abgebildet sein. Erstens: Kernel-Versions-Drift. eBPF-Programme sind eng an die Kernel-Schnittstelle gebunden, die zwischen Kernel-Versionen wechseln kann. Wer auf langlebige Worker-Nodes setzt, muss CO-RE (Compile Once, Run Everywhere) ernst nehmen, sonst zerschlägt jedes Kernel-Update die Detection-Pipeline.

Zweitens: Performance-Overhead in dichten Clustern. Falco mit moderaten Regeln kostet unter normaler Last 1 bis 3 Prozent Worker-CPU, kann aber in dichten Multi-Tenant-Clustern signifikant höher liegen. Sorgfältige Rule-Performance-Profile und gezielte Filter sind 2026 Pflicht, sonst gehen FinOps-Diskussionen los, die das Programm gefährden.

Drittens: Cloud-Managed-Kubernetes mit lockdown-Lifecycles. AWS EKS, GKE und AKS lassen eBPF-Programme inzwischen zu, aber mit unterschiedlichen Restriktionen. Wer Multi-Cloud-K8s betreibt, muss eine konsistente Detection-Strategie über die Plattformen hinweg aufbauen, nicht jeden Cluster eigen.

Häufige Fragen

Ersetzt eBPF-Detection klassische EDR im Cluster?

Nein. Klassische EDR bleibt für Host-Ebene und Worker-Node-Compromise relevant. eBPF-basierte Tools schließen die Container-Sichtlücke und erweitern den Stack. Eine moderne Cluster-Detection 2026 kombiniert EDR auf Worker-Ebene mit Falco oder Tetragon auf Pod-Ebene und mit Network-Detection auf Mesh-Ebene.

Wie hoch ist der Performance-Overhead von Falco in der Produktion?

Bei moderaten Regeln liegt der CPU-Overhead pro Worker-Node typischerweise zwischen 1 und 3 Prozent. In dichten Multi-Tenant-Clustern mit aggressiven Regeln können 5 bis 8 Prozent auftreten. Wer Rule-Performance-Profile aktiv pflegt, hält den Overhead im einstelligen Prozentbereich.

Welche Lernkurve müssen SOC-Teams für eBPF einplanen?

Realistisch zwei bis vier Wochen für Falco bis zur produktiven Rule-Pflege, vier bis acht Wochen für Tetragon. Wichtiger als die Tool-Vertiefung ist die Detection-Engineering-Praxis: MITRE-ATT&CK-Mapping, CI für Regeln, Alert-Triage-Loops. Ohne diese Praxis bleibt eBPF eine teure Telemetrie-Quelle.

Sollte man Falco und Tetragon gleichzeitig einsetzen?

In großen Clustern ab zwanzig Worker-Nodes und mehreren sensiblen Namespaces lohnt sich der parallele Betrieb. Falco bringt breite Coverage und SIEM-Anbindung, Tetragon vertieft Process-Genealogy und liefert Enforcement. In kleineren Setups reicht meistens Falco allein.

Wie verändert eBPF die NIS2-Compliance-Diskussion?

Positiv. NIS2-Pflichtige müssen Detection- und Response-Fähigkeiten nachweisen. eBPF-basierte Telemetrie verbessert die Audit-Trail-Qualität signifikant, weil Kernel-Syscalls die belastbarste Quelle für Forensik sind. Wer 2026 sein NIS2-Set ohnehin aufrüsten muss, sollte eBPF-Coverage als Argument einrechnen.

Lesetipps der Redaktion

• Detection-Engineering ohne Vendor-Lock: Wazuh-Stack 2026
• Selbst-Replikation: KI-Agenten von 6 auf 81 Prozent
• AI-Phishing: Mail-Filter werden blind

Mehr aus dem MBF Media Netzwerk

cloudmagazinMulti-Cluster ohne neues Ops-Silo: was Teams falsch lösen

MyBusinessFutureCloud-Kosten sind Chefsache: Wenn CFO und CIO nicht mehr nebeneinander herrechnen

Digital ChiefsRechenkapazität wird Lieferkette: Compute als knapper Produktionsfaktor 2026

Quelle Titelbild: KI-generiert via nano

Hier schreibt Alec Chizhik für Sie

Mehr Artikel vom Autor Alec Chizhik