Tetragon: eBPF-Sicherheitsbeobachtung und Runtime-Enforcement von Cilium

Tetragons eBPF-Sensoren an kritischen Kernel-Hooks

Tetragon ist eine Komponente des Cilium-Ökosystems, die laut README Echtzeit-Sicherheitsbeobachtung und Runtime-Enforcement auf eBPF-Basis bietet. Der Ansatz unterscheidet sich von klassischen Audit-Daemonen dadurch, dass die Erkennung direkt im Linux-Kernel sitzt: Sensoren hängen sich an sicherheitskritische Hooks und erzeugen Ereignisse, die bereits mit Linux- und Kubernetes-Metadaten angereichert sind. Das Projekt ist in C geschrieben, steht unter Apache-2.0 und zählt rund 4.960 Sterne bei 594 Forks.

Die drei Kategorien, die das README nennt, sind Prozessausführungsereignisse, Systemaufrufaktivität und I/O-Aktivität einschließlich Netzwerk- und Dateizugriff. Wichtig ist die Formulierung detect and react: Tetragon versteht sich nicht als passive Log-Pipeline, sondern kann auf erkannte Ereignisse zur Laufzeit reagieren, etwa durch Durchsetzung von Regeln am Ort des Geschehens. Wie diese Reaktion im Detail konfiguriert wird, verweist das README an die Dokumentation unter tetragon.io; die Projektwebsite ist zugleich der zentrale Dokumentationsort.

process_exec und process_kprobe: zwei Ereignisfamilien

Die Ereigniserzeugung gliedert sich laut README in zwei Familien. Die erste ist der Prozesslebenszyklus: Standardmäßig entstehen process_exec- und process_exit-Ereignisse, womit jede Ausführung und jedes Ende eines Prozesses auf dem Host sichtbar wird, ohne dass man etwas konfigurieren muss. Das deckt den häufigsten Einstiegsfall ab, nämlich die Frage, was auf einem Knoten tatsächlich läuft.

Die zweite Familie ist generisches Tracing mit drei Ereignistypen: process_kprobe für Kernel-Funktionen, process_tracepoint für statische Tracepoints und process_uprobe für Userspace-Funktionen in Binaries und Bibliotheken. Diese Typen richten sich an fortgeschrittene Fälle, die über die Standardbeobachtung hinausgehen. Das README listet als Beispiele Netzwerkbeobachtbarkeit, Dateinamenzugriff, Überwachung von Linux-Prozess-Credentials und privilegierte Ausführung, jeweils mit eigener Dokumentationsseite auf tetragon.io. Ob die generischen Tracing-Typen ohne eigene Richtlinie Ereignisse liefern, sagt das README nicht; nach der TracingPolicy-Konzeptseite ist eine solche Richtlinie die Voraussetzung.

TracingPolicy: kprobe, tracepoint und uprobe konfigurieren

Das Konfigurationselement für das generische Tracing heißt TracingPolicy und hat auf tetragon.io eine eigene Konzeptseite. Über sie legt man fest, welche Kernel-Funktionen oder Symboladressen beobachtet werden, welche Argumente erfasst und welche Selektorenfilter gelten. Weil kprobe-Aufrufe tief in den Kernel eingreifen, ist das der mächtigste, aber auch vorsichtig zu behandelnde Mechanismus: Eine fehlerhafte Richtlinie kann Kernelpfade betreffen, die man besser unberührt lässt.

Für den produktiven Einsatz heißt das, Richtlinien nicht ad hoc zu erfinden, sondern aus den dokumentierten Anwendungsfällen zu starten und schrittweise zu verschärfen. Die use-case-Seiten auf tetragon.io liefern Beispiele für Dateizugriffe, Credentials und privilegierte Ausführung, die als Vorlage dienen können. Was das README an dieser Stelle nicht bietet, sind vollständige YAML-Beispiele oder Payload-Strukturen; wer die Details braucht, kommt um die Lektüre der Referenz unter tetragon.io/docs/reference nicht herum.

Kubernetes-Identitäten statt reiner Host-Sicht

In Kubernetes-Umgebungen ist Tetragon laut README Kubernetes-aware: Es versteht Identitäten wie Namespaces und Pods, sodass Sicherheitsereignisse einzelnen Workloads zugeordnet werden können. Das ist der praktische Unterschied zu Host-Level-Tools, bei denen ein Container-Ausbruch als anonymer Prozess im Log landet. Mit Tetragon erscheint derselbe Vorgang direkt mit Namespace-, Pod- und Container-Kontext, was Alarme deutlich nachvollziehbarer macht.

Die Konfiguration erfolgt damit auf Workload-Ebene, nicht nur global pro Knoten. Für Betreiber mehrerer Teams auf geteilten Clustern bedeutet das, dass man etwa die Überwachung privilegierter Ausführung auf die Namespaces beschränken kann, in denen sie besonders riskant ist. Das README beschreibt die genaue Syntax für diese Einschränkung nicht; nach der Struktur der Dokumentation gehört sie in den Zusammenhang der TracingPolicy und der Installationsanleitung für Kubernetes unter tetragon.io/docs/getting-started/install-k8s.

Einstieg über tetragon.io und die Tetra CLI

Das README selbst enthält keine kopierbaren Installationsbefehle; es verweist auf vier dokumentierte Wege: Tetragon auf Kubernetes ausprobieren, auf Linux ausprobieren, Tetragon deployen und die Tetra-CLI installieren. Die CLI ist das Kommandozeilenwerkzeug, mit dem sich laufende Ereignisströme ansehen und filtern lassen; ihre genaue Benutzung zeigt die Seite tetragon.io/docs/installation/tetra-cli. Für lokale Entwicklung existiert ein Contribution Guide, und wer Pull-Requests einreicht, muss seine Commits mit einem Sign-off versehen, verankert im Developer Certificate of Origin.

Die Release-Historie zeigt ein moderates Tempo: v1.7.0 erschien am 29. April 2026, v1.6.1 am 31. März 2026, und v1.7.1 am 25. August 2026. Wer eine Version für den Produktionsbetrieb wählt, sollte die Patch-Notes auf GitHub gegen die eigene Kernel-Version abgleichen, denn eBPF-Funktionen hängen eng an der Kernel-Fähigkeit des Hosts. Eine Mindest-Kernelversion nennt das README nicht, sie liegt in der FAQ und Installationsdokumentation unter tetragon.io.

Grenzen von Tetragon v1.7.1 im Alltag

Eine ehrliche Einschätzung braucht Grenzen. Erstens verlangt der eBPF-Ansatz einen hinreichend aktuellen Linux-Kernel; auf älteren Distributionen oder spezialisierten Hosts kann der Sensorstack eingeschränkt sein, was das README an keiner Stelle quantifiziert. Zweitens hängt die Nützlichkeit der generischen Tracing-Ereignisse vollständig an der Qualität der TracingPolicy-Dateien, die man selbst pflegt; ohne eigene Richtlinien bleibt man auf die Prozesslebenszyklus-Events beschränkt.

Drittens ist der Umfang des Projekts kleiner als der von Cilium selbst: 266 offene Issues bei rund 4.960 Sternen deuten auf eine aktive, aber überschaubare Community hin. Wer Organisationen in Produktion sucht, findet sie in der Datei USERS.md im Repository, die das README als Beleg für produktive Adoptionen nennt; konkrete Namen stehen dort, nicht im README. Als Alternative für Teams, die nur Prozessaudit ohne Kubernetes-Bezug brauchen, kann ftrace-basiertes Auditing oder auditd genügen; Tetragon zahlt sich aus, wenn die Verknüpfung von Kernel-Ereignissen mit Pod-Identitäten der eigentliche Mehrwert ist.

Redaktionelles Fazit

Tetragon passt für Teams, die Sicherheitsereignisse auf Kernel-Ebene mit Kubernetes-Kontext korrelieren wollen und bereit sind, TracingPolicy-Dateien selbst zu schreiben. Ungeeignet ist es, wenn der Host-Kernel keine aktuellen eBPF-Funktionen mitbringt oder eine reine Kernel-lose Überwachung gesucht wird. Vor dem Rollout sollte man auf tetragon.io die geting-started-Anleitung für Kubernetes durchspielen und die Mindestanforderungen an die Kernel-Version verifizieren.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes