© Serhii Lukutin / 123RF.com

Tetragon, eine umfassende Sicherheitssuite für Kubernetes auf Basis von eBPF, befasst sich mit Überwachung und proaktiver Bedrohungserkennung. Zudem bietet das Tool Tracing für gängige Programmiersprachen.

Die Angriffsszenarien werden immer komplexer; genauso wie die Infrastruktur, die Unternehmen betreiben, um ihrer IT eine Heimat zu geben. Kubernetes samt der darauf laufenden Mikroarchitekturanwendungen mit seinen vielen Schichten für Speicher und Netzwerk ist ein anschauliches Beispiel für stetig wachsende Komplexität. Kein Wunder also, dass Sicherheit zu den zentralen Themen der IT-Verantwortlichen zählt.

Offensichtlich bedarf es hier frischer Werkzeuge. In den vergangenen Jahren sind neue Lösungen entstanden, die Administratoren das Erkennen von Bedrohungen und Angriffen in skalierbaren Umgebungen erleichtern. Das in der letzten Ausgabe besprochene Falco [1] ist dafür ein Beispiel. Als direkter Konkurrent von Falco [2] tritt Tetragon [3] an, um das es hier gehen soll.

Das Werkzeug verspricht, wie Falco, die proaktive Überwachung von containerisierten Setups in Kubernetes. Das ist nicht die einzige Parallele: Wie der Konkurrent setzt auch Tetragon stark auf die virtuelle Kernel-Netzwerkmaschine eBPF, um laufende Paketströme mitzuschneiden und zu analysieren. Das liegt nahe, denn Tetragon entspringt der Feder der Entwickler von Cilium, einer der bekanntesten Implementierungen von Software Defined Networking (SDN) für Kubernetes.

Tetragon deckt jedoch ein größeres Aufgabengebiet ab als Falco. Neben der bereits beschriebenen Überwachung von Programmen und Datenströmen zur Laufzeit bietet es umfassende Möglichkeiten für Monitoring, Alerting und Trending. Hinzu kommt eine Tracing-Funktion, die sich auf der Ebene eines Programms einbauen und nutzen lässt. Dieser Artikel stellt Tetragon im Detail vor und geht auf die Stärken und Schwächen des Werkzeugs ein.

Komplexe Architektur

Auch bei Tetragon hilft ein Architekturdiagramm (Abbildung 1) beim Verstehen der Lösung. Es wird schnell deutlich, dass es zwar Parallelen zu Falco gibt, aber auch deutliche Unterschiede.

Abbildung 1: Tetragon klinkt sich per eBPF in den Linux-Kernel ein und implementiert dort Funktionen zur Überwachung sowie zum aktiven Eingreifen. Überdies lassen sich die gesammelten Daten umfassend exportieren. Quelle: Isovalent

Beide Werkzeuge setzen auf eBPF. Zur Erinnerung: eBPF, der Extended Berkeley Packet Filter, ist eine In-Kernel-VM, die allerdings nicht auf den Betrieb generischer virtueller Maschinen ausgelegt ist wie KVM. Stattdessen führt eBPF kleine, auf Netzwerkdaten spezialisierte Programme aus, die es unmittelbar mit den jeweiligen Datenströmen verknüpft. Dabei besticht eBPF vor allem mit seiner Performance. Seine Architektur versetzt es in die Lage, Netzwerkverkehr quasi in Echtzeit auszuleiten oder zu manipulieren.

Genau hier setzt Tetragon an: Es hinterlegt eBPF-Programme im Linux-Kernel. Diese nutzen in eBPF definierte Hook Points, also bestimmte Ereignisse, die eBPF beim Durchleiten von Traffic besonders hervorhebt. Zur Auswahl stehen die drei Hook Points »tracepoint« für das Nachverfolgen von Paketströmen, »kprobe« für Ereignisse, die mit einem Systemaufruf des Linux-Kernels zusammenhängen, sowie »uprobe«, das auf Programmaufrufe im User Space spezialisiert ist.

Kprobes hängen sich dabei an Aufrufe wie »system« oder »execve«, um relevante Ereignisse zu erfassen. Bei Uprobes ist die Eingrenzung schwieriger: Hier kann wirklich jede Funktion verwendet werden, die ein beliebiges Programm im Userspace definiert. Entsprechend kennt eBPF auch Unterschiede zwischen dem Abfangen von Kprobe- und Uprobe-Aufrufen. Erstere kann eBPF nativ und direkt im Linux-Kernel mitschneiden. Bei Letzteren hingegen bedarf es einer eigenen Integration in das jeweilige Programm, sonst funktioniert das Mitschneiden von Daten nicht. Uprobes sind entsprechend der Teil von Tetragon, der für Tracing von Daten innerhalb von Anwendungen zum Einsatz kommt. Zusammen ergeben Tracepoints, Uprobes und Kprobes ein mächtiges Gespann.

Wichtig ist, dass eBPF eine generische Programmierschnittstelle bereitstellt, damit Programme eigene Funktionen erstellen und im Kernel verwenden können. Tetragon geht pragmatisch ans Werk und nutzt etwa »matchArgs«, um bestimmte Werte zu überwachen, die Programmen und Funktionen als Argument übergeben werden. Mittels »matchPIDs« lassen sich laufende Paketströme im Hinblick auf die Prozess-IDs (PIDs) überwachen, von denen sie ausgehen. Daneben erlaubt »matchActions« das selektive Filtern anhand bestimmter Ereignisse. Diese Funktionen sind der Kern des Werkzeugs.

Nicht nur Kubernetes

Zwar stellen seine Entwickler Tetragon mit klarem Fokus auf Kubernetes zur Verfügung, ein sinnvoller Betrieb ist aber auch außerhalb von Kubernetes möglich – wenn auch mit weniger Komfort.

Im einfachsten denkbaren Tetragon-Setup installieren Sie lediglich das in Go geschriebene Tetragon-Binary. Sie starten es mit Root-Rechten und stellen sicher, dass Systemd das Werkzeug mithilfe einer Unit dauerhaft am Laufen hält. Der Tetragon-Daemon läuft dann im Hintergrund. Auf der Kommandozeile steht ein eigenes CLI-Kommando zur Verfügung, das ebenfalls »tetragon« heißt. Das Kommando »tetragon getevents -o compact« produziert selbst auf einem System ganz ohne Container bereits eine chronologische Übersicht über Ereignisse, die den Start oder das Beenden von Prozessen betreffen (Abbildung 2).

Abbildung 2: Tetragon kann Ereignisse per JSON oder gRPC exportieren. Die einfachste Ansicht ist aber die Ausgabe auf der Kommandozeile. Hier sind verschiedene Programmaufrufe dokumentiert.

Möchten Sie mehr über ein System erfahren, stehen Ihnen Regelwerke zur Seite. Sie kommen im recht übersichtlichen YAML-Format daher und heißen im Tetragon-Sprech Policy. Das Tetragon-Projekt selbst stellt einen Grundschatz an Policies in seinem Github-Verzeichnis zur Verfügung. Dort findet sich unter anderem eine Policy, um eBPF-Ereignisse abzufangen und aufzuzeichnen.

Daneben ist eine Beispiel-Policy für das Überwachen von Werkzeugen hinterlegt, die konkret für den SSH-Daemon Sshd funktioniert. Sie sorgt dafür, dass Tetragon ein Event aufzeichnet, wenn ein Prozess namens »sshd« oder »tcpserver« bestimmte Systemaufrufe tätigt, etwa eine TCP-Verbindung öffnet. Dabei zeichnet Tetragon auf, welcher Host die Verbindung initiiert hat und wer das Ziel war. Versuchen Gauner sich per SSH mit einem System zu verbinden, lässt sich das mittels Tetragon automatisiert erkennen und ein entsprechender Alarm auslösen.

Das Listing 1 enthält ein kurzes, aber aussagekräftiges Beispiel für eine Policy in Tetragon. Sie ist zwar für die Verwendung in Kubernetes gedacht, deutlich zu erkennen am Verweis auf die Netzwerkmaske eines Pods – ein typisches Kubernetes-Konzept. Ansonsten ist das Beispiel aber eingängig: Wenden Sie die Regel aus dem Beispiel an, erkennt sie den Aufbau ausgehender TCP-Verbindungen zu externen Hosts.

Dafür sorgt der gesamte Block ab »kprobes«: Er definiert eine eBPF-Regel auf Grundlage der Kprobe-Funktion, die dann greift, wenn »tcp_connect« benutzt wird. Das ist kein Linux-Systemaufruf, sondern eine Funktion der C-Standardbibliothek. Entsprechend steht der Parameter »syscall« auf »false«. Die »selectors« grenzen die Auswahl dann ein. Der Parameter »matchArgs« leitet einen Absatz ein, der die Einschränkungen enthält.

Die laufende Nummer der Regel gibt »index« an. Der »operator« definiert, dass die eBPF-Regel nur greift, wenn die Zieladresse (“destination address”, kurz »DAddr«) weder im eigenen POD-Netz der laufenden Anwendung liegt, noch im Netz der Service-Adresse, über die Kubernetes den Dienst zur Außenwelt hin exponiert, und nicht »127.0.0.1« ist, also »localhost«. Mittels der einschränkenden Regeln filtern Sie also interne Verbindungen aus dem Ergebnis. Als Ausgabe des eBPF-Programms sehen Sie demgemäß nur ausgehende Verbindungen des Diensts in die Außenwelt.

Daneben steht ein »notSAddr«-Parameter zur Verfügung, über den Sie ein umgekehrtes Szenario implementieren: Dann erkennt das Programm ausgehende Verbindungen, die nicht von bestimmten, als vertrauenswürdig definierten Quelladressen stammen.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "monitor-network-activity-outside-cluster-cidr-range"
spec:
  kprobes:
  - call: "tcp_connect"
    syscall: false
    args:
    - index: 0
      type: "sock"
    selectors:
    - matchArgs:
      - index: 0
        operator: "NotDAddr"
        values:
        - 127.0.0.1
        - ${PODCIDR}
        - ${SERVICECIDR}

Im Gespann mächtiger

Verwenden Sie Tetragon lediglich als eigenständiges Binary, also zur Überwachung der Ressourcen auf einem Host, dann nutzen Sie nur einen Teil der Funktionalität der Lösung. Tetragon ist weit mehr als ein Verwaltungswerkzeug mit eigenem Daemon, der auf einem System Ereignisse per eBPF erkennt und aufzeichnet. Seine volle Kraft entfaltet es erst, wenn Sie es im Gespann mit Kubernetes und Helm einsetzen.

Darüber hinaus gehört zu Tetragon auch ein eigener Agent, der als Anknüpfungspunkt für typische Monitoring- und Tracing-Werkzeuge fungiert. Hier halten sich die Entwickler an Standards: Auf Wunsch steht der Tetragon-Agent etwa Prometheus über eine eigens dafür konzipierten Schnittstelle Rede und Antwort. Log-Dateien lassen sich aus Tetragon heraus nativ für Loki oder Elasticsearch bereitstellen. Für das Tracing steht eine Open-Observability-Schnittstelle bereit. Zudem werben die Entwickler mit umfassender Anbindung an SIEM-Umgebungen und Fluentd.

Eine Frage des Deployments

Wie funktioniert Tetragon in einem größeren Kontext im Detail? Das kommt auf die Art und Weise an, wie Sie in Ihrer Umgebung Tetragon ausrollen und betreiben. Das wiederum hängt davon ab, mit welcher Art von Plattform Sie es zu tun haben. Immerhin: Kubernetes zeichnet sich ja gerade dadurch aus, dass es standardisierte APIs für Standardaufgaben zur Verfügung stellt. Solange Sie also Kubernetes und nicht andere Containerorchestrierer wie Nomad oder Docker Swarm verwenden, können Sie auf die umfassende, von Tetragon selbst zur Verfügung gestellte Integration in Kubernetes zurückgreifen. Sie fußt ihrerseits vor allem auf dem Kubernetes-Softwaremanager Helm.

Entsprechend trivial gestaltet sich die Installation. Die drei Befehle aus Listing 2 reichen aus, um die Grundinstallation von Tetragon in einer Kubernetes-Installation zu erledigen. Dabei holen Sie sich mehrere Komponenten in die Umgebung. Mit an Bord ist vor allem ein eigener Kubernetes-Operator für Tetragon.

$ helm repo add cilium https://helm.cilium.io
$ helm repo update
$ helm install tetragon cilium/tetragon -n kube-system

Im Kubernetes-Sprech ist ein Operator eine Sammlung sogenannter Custom Resource Definitions, kurz CRDs. Kubernetes versucht im Kern ja, alle anfallenden Aufgaben im Rechenzentrum in Software abzubilden und per API steuerbar zu machen. Weil die Kubernetes-API dabei selbst aber nicht jedes denkbare Szenario abfangen kann, bietet sie die Möglichkeit, Custom Resource Definitions zu hinterlegen. Die erweitern die Kubernetes-API und bringen ihr so bei, zusätzliche Funktionen zu unterstützen.

Tetragon macht davon ausgiebig Gebrauch: Sind die CRDs für Tetragon in Kubernetes hinterlegt, lassen sich Tetragon-Policies über die Kubernetes-API ebenso definieren wie die Anbindung an verschiedene Überwachungsdienste. Der Tetragon-Operator ist insofern integraler Bestandteil der Lösung. Er ist aber nicht die einzige Komponente, die mit Helm kommt.

Zum Setup gehört auch eine im Kubernetes-Cluster dauerhaft laufende Instanz von Tetragon selbst als Control Daemon. Sie steuert die Tetragon-Geschicke über die gesamte Kubernetes-Installation hinweg in Form eines Servers. Ein Server in Kubernetes braucht jedoch zwingend ein Gegenstück auf den einzelnen Systemen, das die Anweisungen der Zentrale entgegennimmt und dort in konkrete Konfiguration ummünzt. Dafür kommt auf den einzelnen Clusterknoten der Installation das Tetragon-Programm selbst zum Einsatz, dann aber im Agenten-Modus.

Dank der umfassenden Integration in Kubernetes per Operator kümmert sich Tetragon automatisch um Faktoren wie Redundanz und Hochverfügbarkeit. Die Tetragon-Server-Instanz beispielsweise ist als Kubernetes-ReplicaSet angelegt. Fällt eine Instanz des Diensts aus, sorgt Kubernetes also automatisch dafür, dass der Dienst an anderer Stelle erneut startet.

Bessere Integration

Wie bereits beschrieben folgt Tetragon anders als Falco einer “Kubernetes-First”-Richtlinie. Das heißt konkret, dass die Integration von Tetragon in Kubernetes deutlich besser ist als jene von Falco, und zwar bis tief in die Interna von Kubernetes hinein.

Ein Beispiel verdeutlicht das schnell: Falco fußt auf dem Prinzip, laufende Prozesse in Kubernetes zu überwachen, im Userland zu analysieren und bei Bedarf Alarm zu schlagen. Zwar dockt auch Falco per eBPF an laufende Prozesse an. Hinsichtlich der Nutzung der von eBPF bereitgestellten Funktionen hält sich Falco allerdings zurück. So besteht beispielsweise die Option, in einem eBPF-Programm bestehende Datenströme und Ereignisse nicht nur zu erfassen, sondern sie auch zu beeinflussen. Falco indes beschränkt sich darauf, bei bestimmten Ereignissen über die vom Administrator definierten Kanäle Alarm zu schlagen.

Tetragon geht die Sache sehr viel handfester an: Im Rahmen einer Tetragon-Policy stehen Ihnen alle Werkzeuge zur Verfügung, die eBPF anbietet. Das umfasst auch die Möglichkeit, aktiv in die Ereignisse auf Systemen automatisiert einzugreifen.

Gegeben sei etwa ein Szenario, in dem Sie möchten, dass einzelne Programme aus Ihrer Plattform heraus nur mit bestimmten externen Adressen kommunizieren. Das kommt insbesondere in Umgebungen mit komplexen Compliance-Anforderungen regelmäßig vor. Früher war es üblich, nur eingehende Verbindungen zu untersuchen und gegebenenfalls zu blockieren, damit Eindringlinge kein Einfallstor finden. Mittlerweile gilt aber auch nicht genehmigter Traffic von drinnen nach draußen als Problem. Er kann ein Hinweis darauf sein, dass einem Gauner bereits ein Einbruch gelungen ist und er nun aktiv Daten stiehlt oder die vorhandenen Ressourcen für andere illegale Aktionen nutzt.

Bereits mit Falco lässt sich derlei unerwünschter Datenverkehr problemlos identifizieren. Über die Verbindung zu Werkzeugen wie Prometheus startet dann die Alarmierung. Im nächsten Schritt müssen Sie dann aber prüfen, ob der identifizierte Traffic wirklich unerwünschten Ursprungs ist, und gegebenenfalls eingreifen. Tetragon bietet mehr Möglichkeiten: Hier lässt sich eine Policy so gestalten, dass ausgehender Traffic im Falle eines Falles nicht nur erkannt wird und einen Alarm auslöst, sondern dass eBPF ihn auch direkt blockiert. Eine Benachrichtigung über den Vorgang erhalten Sie trotzdem. Sie müssen jedoch nicht unmittelbar eingreifen, um eine mögliche Gefahr abzuwehren.

Was dabei ebenfalls auffällt: Weil Tetragon die Analyse von Traffic und anderen Aktionen direkt per eBPF abwickelt, geht es deutlich flotter ans Werk als Falco. Falco leitet Aufzeichnungen über Ereignisse lediglich aus der Event-API des Linux-Kernels ab, muss die Analyse dann aber im Userland des jeweiligen Systems ausführen. Tetragon hingegen nutzt die eBPF-Funktionen im Kernel nativ.

Schätzungen gehen davon aus, dass Falco 8 bis 10 Prozent der Ressourcen einer Umgebung braucht, um seine Aufgaben abzuwickeln. Tetragon hingegen begnügt sich mit weniger als 1 Prozent Overhead. Das ist ein Hinweis auf die Effizienz, die eBPF mittlerweile liefert, und belegt, dass eBPF trotz seines Namens längst mehr als ein erweiterter Paketfilter ist. Stattdessen hat es sich in den vergangenen Jahren zum umfassenden Werkzeug entwickelt, um Compliance und Sicherheit nicht nur zu überwachen, sondern auch zu erzwingen.

Performance schreiben die Tetragon-Entwickler übrigens auch an anderer Stelle groß. Weil Policies in Tetragon grundsätzlich Kubernetes verstehen und sich in den Orchestrierer integrieren, erledigen sie die Integration von eBPF-Regeln auf den Hosts üblicherweise über die Kubernetes-API und den K8s-Agenten auf den Zielsystemen, das sogenannte Kubelet. Das allerdings führt zur Laufzeit möglicherweise zu kurzen Verzögerungen beim Starten des Containers. Das ist etwa dann der Fall, wenn es gilt, auf einem Compute-Knoten einen Container zu starten, das Kubelet aber noch mit anderen Aufgaben beschäftigt ist.

Mittels der Runtime Hooks schafft Tetragon Abhilfe: Sind sie aktiviert, klinkt sich Tetragon auf den Compute Nodes direkt in die Laufzeitumgebung für Container ein, üblicherweise also Podman oder Docker, und sorgt dafür, dass etwaige Regeln unmittelbar von ihnen implementiert werden. Unter der Haube laufen dann zwar mehr Dienste im Hintergrund auf den einzelnen Systemen, dafür entfallen jedoch jedwede Verzögerungen.

Kubernetes zuerst

Die “Kubernetes-zuerst”-Politik seiner Entwickler verschafft Tetragon an dieser Stelle weitere Vorteile. Weil Tetragon darauf ausgelegt ist, nativ mit Kubernetes zu kooperieren, versteht es dessen interne Struktur und dockt an sie an. Wo alternative Lösungen wie Falco über externe Werkzeuge so ausgerollt werden müssen, dass sie einzelnen Diensten in Kubernetes als Beiwagen (Sidecar) dienen, kommuniziert Tetragon mit der Kubernetes-API nativ und interpretiert sie entsprechend. Das wird am Beispiel der Integration in andere Dienste deutlich.

Auch wenn im vorherigen Abschnitt der Eindruck entstanden sein mag, die Benachrichtigung über Ereignisse sei bei Tetragon lediglich eine nette Zusatzfunktion, steht Überwachung und Alarmierung bei den Entwicklern der Lösung doch ganz weit oben auf der Prioritätenliste. Dafür gibt es die bereits erwähnte Integration in externe Werkzeuge.

In skalierbaren Umgebungen gilt heute beispielsweise das Gespann aus Prometheus, seinem Alert Manager und Grafana als Königsweg für Monitoring, Alerting und Trending (MAT). Prometheus sammelt dabei als Zeitreihendatenbank Metrikdaten aus der gesamten Installation und speichert sie. Anhand von Regeln, die der Administrator festlegt, generiert Prometheus bei Vorliegen bestimmter Metrikdatenwerte Alarme und übergibt sie seinem Alert Manager zur Auslieferung. Mittels Grafana ist es zudem leicht möglich, die hinterlegten Metrikdaten zu visualisieren.

Damit Kubernetes Metrikdaten eines Diensts sinnvoll einsammeln kann, muss der die Daten allerdings auch im geeigneten Format bereithalten. Das tun sowohl Falco als auch Tetragon von sich aus. Beide Werkzeuge haben also eine Metrics-Schnittstelle, die Prometheus direkt abfragt (Abbildung 3). Große Unterschiede ergeben sich allerdings hinsichtlich der Einbettung von Tetragon oder Falco in Kubernetes: Bei Falco fällt sie als Fleißarbeit dem Administrator zur Last.

Abbildung 3: Verbindet man sich per HTTP mit Tetragon auf Port 2112, gelangt man zur Metrikschnittstelle für Prometheus.

Tetragon hingegen integriert sich von allein in den Kubernetes-Prometheus-Stack, der sich mittels des Operators von Prometheus schnell installieren lässt. Den wiederum beschafft Helm. Zwar sind in der Konfiguration des Helm-Charts für den jeweiligen Cluster ein paar Einträge nötig, die die Tetragon-Doku auch explizit beschreibt [4]. Sind diese Einstellungen jedoch erst einmal hinterlegt, erkennt eine per Operator in Kubernetes ausgerollte Prometheus-Instanz die von Tetragon bereitgestellten Endpunkte automatisch als Ziel für ihre Abfragen. Lediglich das Erstellen passender Dashboards in Grafana bleibt dann an Ihnen hängen. Dafür aber finden sich im Grafana-Marktplatz entsprechende Muster [5] (Abbildung 4).

Abbildung 4: Tetragon lässt sich aus Kubernetes heraus automatisch mit Prometheus verbinden. Entsprechende Dashboards von Cilium finden sich im Grafana-Marktplatz. Quelle: Isovalent

Ereignisse exportieren

Fernab von klassischem MAT bietet Tetragon zudem die Möglichkeit, Ereignisse jedweder Art in Richtung Außenwelt zu exportieren. Dafür existieren im Werkzeug mehrere Schnittstellen. So bietet Tetragon einerseits ein Interface zum Export der Rohdaten der Ereignisse im YAML-Format. Das zwingt Sie aber zur Handarbeit, denn eine fertige Parser-Funktion existiert für das Format nicht. Wenigstens lassen sich noch auf der Tetragon-Ebene Filter für die Ausgabe definieren. Das steigert die Performance und vermeidet die Notwendigkeit, aus einer Unmenge an Ereignisbenachrichtigungen die richtigen herauszusuchen.

Möchten Sie die JSON-Schnittstelle nicht selbst auswerten, lassen Sie das einen geeigneten Dienst erledigen, etwa Fluentd und dessen JSON-Parser. So erschlagen Sie dann gleich auch die Anbindung an beliebige SIEM-Systeme. Zudem bietet Tetragon eine Schnittstelle für gRPC. Verarbeiten Sie die Events lieber auf der Kommandozeile, nutzen Sie die Tetra-CLI.

Fazit

Tetragon präsentiert sich als umfassendes und vollständiges Werkzeug, besonders für Workloads, in denen Kubernetes eine wichtige Rolle spielt. Hier glänzt es im Gegensatz zu Falco mit einer tiefgreifenden Integration und vielen durchdachten Funktionen, die dieser Artikel aber nicht alle im Detail beleuchten konnte.

Erwähnenswert wären etwa die umfassenden SDKs (Abbildung 5) gewesen, die sich direkt in Programme integrieren lassen und durch die Tetragon auf Basis von eBPF umfassendes Tracing realisiert [6]. In Anbetracht der Tatsache, dass sich im Netz viele Beispiele und Muster für die Integration von Tetragon in laufende Kubernetes-Setups finden, sollte das Tool eine Ihrer ersten Anlaufstellen sein, wenn Sie proaktive Sicherheitsfunktionen für Kubernetes suchen und schnell verwertbare Ergebnisse benötigen. (jcb)

Abbildung 5: Die Tracing-Funktionen in Tetragon ermöglichen das Verfolgen von Informationen in einem Gestrüpp aus Kommunikationsendpunkten, wie es bei Mikroarchitekturen oft gegeben ist. Dazu klinkt sich das Werkzeug auf Compute Nodes tief in die Anwendungskommunikation ein. Quelle: Isovalent