Isovalent Tetragon
Aufpasser im Untergrund
Veröffentlicht in Ausgabe 12/2025 - TESTS
Kubernetes ist längst das Betriebssystem der Cloud. Was als Orchestrierer für Container begann, ist heute die universelle Plattform für Microservices und APIs – in Rechenzentren, in der Public Cloud und am Edge. Diese Dynamik macht Entwicklungsteams flexibel, stellt Sicherheitsverantwortliche jedoch vor Herausforderungen. Container leben kurz, IP-Adressen wechseln häufig, Servicetopologien ändern sich fast minütlich. Eine Schutzstrategie, die auf statische Perimeter setzt, läuft zwangsläufig hinterher. Millionen Events pro Tag erschweren die Korrelation, Kontext fehlt oft genau dann, wenn er am dringendsten gebraucht würde.
Sicherheit in Kubernetes bedeutet heute, das Zusammenspiel aus Workloads, Policies und Identitäten zu verstehen. Zugriffe erfolgen über Service-Accounts und Admission-Regeln; Kommunikation geschieht über Sidecars, Ingress-Controller und Gateways. Klassische IDS- oder AV-Systeme erkennen zwar Symptome, doch die Ursachen bleiben meist verborgen. Gesucht ist daher Telemetrie mit Tiefenschärfe – nah am Geschehen, ereignisgetrieben und kontextsensitiv.
| Produkt |
eBPF-basiertes Sicherheits- und Überwachungswerkzeug für Kubernetes-Cluster. Es erfasst Kernelereignisse in Echtzeit, ordnet sie Workloads zu und erkennt sicherheitsrelevante Aktivitäten im laufenden Betrieb. |
|---|---|
| Hersteller |
Isovalent
|
| Preis |
Kostenlos; Open Source (Apache License 2.0) |
| Systemanforderungen |
128 MByte RAM, ein CPU-Kern, aktueller Linux-Kernel mit eBPF-Unterstützung, ein laufender, aktueller Kubernetes-Cluster. |
| Technische Daten |
eBPF: Kontrolle auf Kernel-Ebene
Hier kommt eBPF ins Spiel. Die Technologie erlaubt es, Überwachungscode direkt an Schnittstellen des Linux-Kernels anzudocken. Wann immer ein Prozess eine Datei öffnet, einen Socket erstellt oder ein Programm startet, erfasst eBPF das Ereignis nahezu in Echtzeit. Statt periodisch zu scannen, reagiert eBPF auf tatsächliche Systemaufrufe und liefert präzise, verlustarme Telemetrie mit minimalem Overhead.
Kubernetes ist längst das Betriebssystem der Cloud. Was als Orchestrierer für Container begann, ist heute die universelle Plattform für Microservices und APIs – in Rechenzentren, in der Public Cloud und am Edge. Diese Dynamik macht Entwicklungsteams flexibel, stellt Sicherheitsverantwortliche jedoch vor Herausforderungen. Container leben kurz, IP-Adressen wechseln häufig, Servicetopologien ändern sich fast minütlich. Eine Schutzstrategie, die auf statische Perimeter setzt, läuft zwangsläufig hinterher. Millionen Events pro Tag erschweren die Korrelation, Kontext fehlt oft genau dann, wenn er am dringendsten gebraucht würde.
Sicherheit in Kubernetes bedeutet heute, das Zusammenspiel aus Workloads, Policies und Identitäten zu verstehen. Zugriffe erfolgen über Service-Accounts und Admission-Regeln; Kommunikation geschieht über Sidecars, Ingress-Controller und Gateways. Klassische IDS- oder AV-Systeme erkennen zwar Symptome, doch die Ursachen bleiben meist verborgen. Gesucht ist daher Telemetrie mit Tiefenschärfe – nah am Geschehen, ereignisgetrieben und kontextsensitiv.
| Produkt |
eBPF-basiertes Sicherheits- und Überwachungswerkzeug für Kubernetes-Cluster. Es erfasst Kernelereignisse in Echtzeit, ordnet sie Workloads zu und erkennt sicherheitsrelevante Aktivitäten im laufenden Betrieb. |
|---|---|
| Hersteller |
Isovalent
|
| Preis |
Kostenlos; Open Source (Apache License 2.0) |
| Systemanforderungen |
128 MByte RAM, ein CPU-Kern, aktueller Linux-Kernel mit eBPF-Unterstützung, ein laufender, aktueller Kubernetes-Cluster. |
| Technische Daten |
eBPF: Kontrolle auf Kernel-Ebene
Hier kommt eBPF ins Spiel. Die Technologie erlaubt es, Überwachungscode direkt an Schnittstellen des Linux-Kernels anzudocken. Wann immer ein Prozess eine Datei öffnet, einen Socket erstellt oder ein Programm startet, erfasst eBPF das Ereignis nahezu in Echtzeit. Statt periodisch zu scannen, reagiert eBPF auf tatsächliche Systemaufrufe und liefert präzise, verlustarme Telemetrie mit minimalem Overhead.
Im Hintergrund wirken kleine, verifizierte Programme, die der Kernel zur Laufzeit ausführt und über standardisierte Hooks einbindet. Diese Architektur bietet Sicherheit aus der Tiefe des Systems – ohne invasive Agenten oder permanente Polling-Prozesse.
Auf genau diesem Fundament baut Tetragon auf. Das Open-Source-Werkzeug nutzt eBPF, um sicherheitsrelevante Aktivitäten in Kubernetes sichtbar zu machen, sie mit Kontext aus dem Cluster anzureichern und – falls nötig – sofort zu reagieren. Wie gut das in der Praxis funktioniert, haben wir getestet.
Sicherheitskonzept mit Tiefenschärfe
Tetragon ist ein Open-Source-Projekt von Isovalent, den Machern der SDN-Software Cilium. Es kombiniert eBPF-gestützte Laufzeittelemetrie mit einem deklarativen Policy-Modell. Auf jedem Node läuft ein Daemon, der ausgewählte eBPF-Programme lädt, Ereignisse sammelt und sie mit Kubernetes-Metadaten anreichert. So lassen sich Netzwerk- und Systemaktivitäten unmittelbar Ressourcen im Cluster zuordnen – etwa welcher Pod wann welche Verbindungen aufgebaut hat, welche Namespaces oder Images beteiligt waren und welche Service-Accounts im Spiel sind.
Diese Detailtiefe ist im Sicherheitsfall entscheidend, mit herkömmlichen Werkzeugen aber kaum zu erreichen. Tetragon schließt diese Lücke mit eBPF und erzeugt strukturierte Ereignisse in Streams, Logs oder Metriken – und kann darauf reagieren, vom Alarm bis zum Blockieren eines Aufrufs. Ziel ist kein weiteres Logsystem, sondern ein verlässliches, aktuelles Abbild dessen, was Workloads im Cluster tatsächlich tun.
Tetragon positioniert sich bewusst zwischen Monitoring und Prävention. Es sammelt nicht blindlings alles, sondern nur sicherheitsrelevante Ereignisse, und greift nur ein, wenn Policies dies verlangen. Das sorgt für Transparenz ohne Rauschen und Kontrolle ohne Kollateralschäden.
Breit aufgestellt von Enterprise bis Edge
Technisch gibt sich Tetragon erfreulich anspruchslos. Ein moderner Linux-Kernel mit eBPF-Unterstützung, Control Groups v2 und BPF-Maps genügen – Komponenten, die in aktuellen Enterprise-Distributionen wie RHEL, SLES oder Ubuntu LTS längst Standard sind.
Auch Managed-Kubernetes-Angebote wie EKS, AKS und GKE bringen die nötigen Voraussetzungen mit. Nur sehr alte Nodes sollten hinsichtlich Kernel-Version und Hook-Verfügbarkeit geprüft werden.
Tetragon integriert sich nahtlos in bestehende Sicherheitsmechanismen: AppArmor und SELinux bleiben aktiv, Pod Security ersetzt die alten PodSecurityPolicies, während Tetragon auf der darunterliegenden Laufzeitebene arbeitet. Gerade in regulierten Umgebungen liefert das Werkzeug so prüfbare, kontextreiche Evidenz für Audits und Härtungsrichtlinien nach CIS oder ISO.
Im Betrieb zeigt sich Tetragon robust. Ereignisse bleiben lokal erhalten, selbst wenn externe Exportziele wie SIEM-Systeme vorübergehend ausfallen. Puffer und Backpressure-Mechanismen verhindern, dass Lastspitzen das System ausbremsen.
Für revisionssichere Audits empfiehlt sich ein unveränderlicher Event-Store mit WORM-Semantik – ein bewährter Ansatz, um sicherheitsrelevante Daten langfristig aufzubewahren.
Schneller Start trotz Kernelnähe
Trotz seiner Nähe zum Kernel ist Tetragon in wenigen Schritten einsatzbereit. Der einfachste Weg führt über den Kubernetes-Paketmanager Helm. Nach dem Hinzufügen des Cilium-Repositories genügt ein Installationsaufruf im Namespace "kube-system". Das Deployment erfolgt als DaemonSet, wodurch jeder Node automatisch überwacht wird. Bestehende Container-Instanzen bleiben unberührt – der Eingriff in laufende Workloads ist minimal. Feinsteuerung bietet das Helm-Chart selbst: Dort finden sich Parameter für Ausgabekanäle, gRPC-Endpunkte, Exportziele und Filter.
Das Herzstück von Tetragon sind Tracing Policies. Sie definieren, welche Ereignisse beobachtet, wie sie kontextualisiert und welche Reaktionen ausgelöst werden. Der Administrator verteilt Policies als Kubernetes-Ressourcen, versioniert sie und verwaltet sie idealerweise per CI/CD. Neue Regeln greifen unmittelbar, ohne Neustart. Zum Einstieg genügen beobachtende Policies; später lassen sich dieselben Regeln um Aktionen wie das Blockieren verdächtiger Aufrufe erweitern.
Der Nutzen zeigt sich sofort nach dem Deployment: Prozessstarts, Datei- und Netzwerkoperationen oder Capability-Änderungen werden in Echtzeit sichtbar – etwa über das CLI. Beeindruckt hat uns die geringe Systemlast: Während klassische Filterwerkzeuge wie NFtables bei hohen Datenmengen ins Stocken geraten, bleibt eBPF im Kernel nahezu latenzfrei. Statt kryptischer PIDs sahen wir unmittelbar, welche Anwendung welche Aktion ausführte.
Vorbildlich integrierbar und ressourcenschonend
Tetragon fügt sich reibungslos in bestehende Umgebungen ein. Ereignisse lassen sich als JSON in zentrale Log-Pipelines exportieren, über gRPC streamen oder mit OpenTelemetry korrelieren. In Verbindung mit Cilium und Hubble entsteht so ein konsistentes Bild aus Netzpfaden und Prozessereignissen, das Antworten auf Fragen liefert wie: Wer hat wann mit wem kommuniziert und welcher Code hat das ausgelöst?
SIEM-Systeme wie Splunk oder Elastic verarbeiten die strukturierten Events deutlich besser als unstrukturierte Syslog-Fluten. Auch Grafana (Bild 2) visualisiert Metriken aus Tetragon nahezu ohne Zusatzaufwand. Verglichen mit dem Set-upaufwand klassischer Monitoringstacks ist die Inbetriebnahme erstaunlich einfach – nicht zuletzt dank der Integration in Helm.
Wichtig: Tetragon respektiert RBAC und Pod Security (PSA) vollständig. Der Daemon arbeitet mit den nötigen, aber gezielt begrenzten Privilegien; produktive Namespaces bleiben unverändert. Für Multi-Mandanten-Umgebungen empfehlen sich getrennte Export-Sinks und Namespace-Restriktionen, sodass Teams nur ihre eigenen Ereignisse sehen.
Anwendungen selbst erfordern keinerlei Anpassung – keine Sidecars, keine Bibliotheken, keine Codeänderungen. Das reduziert den Aufwand und ermöglicht eine schrittweise Einführung. Genau hier punktet Tetragon gegenüber Ansätzen, die Instrumentierung direkt im Programmcode verlangen. Wer je versucht hat, Konkurrenzprodukte über Sidecars an eigene Workloads anzubinden, erkennt sofort, wie elegant Tetragon respektive eBPF diese Hürde umgeht.
Auch im Zusammenspiel mit Admission-Controllern zeigt sich Tetragon als sinnvolle Ergänzung. Admission Policies verhindern Fehlkonfigurationen beim Roll-out; Tetragon greift in der Laufzeit ein, wenn etwas Unerwartetes passiert – etwa das Nachladen verdächtiger Programme oder auffällige Netzwerkpfade. So erhöht die Software die Resilienz des Clusters spürbar.
Präzise Einblicke statt Lograuschen
Der Mehrwert von Tetragon steht und fällt mit der Qualität seiner Events – und die erwies sich im Test als beeindruckend. Das Werkzeug liefert umfassende, präzise Telemetrie: Prozessstarts mit vollständiger Kommandozeile und Elternprozess, Dateioperationen samt Pfad und Ergebniscode, Netzereignisse mit Adressen und Ports, Capability-Wechsel, Mount-Aktionen, Setuid-Übergänge und mehr. Alle Events sind mit Kubernetes-Metadaten versehen, sodass die Ereigniskette selbst bei Container-Wechseln jederzeit nachvollziehbar bleibt.
Tetragon bringt zudem erprobte Policy-Muster für typische Angriffspfade mit – etwa für interaktive Shells in Produktions-Pods, verdächtige Tools wie curl oder wget in Minimal-Images, Schreibzugriffe auf sensible Pfade oder unerwünschte Outbound-Verbindungen. Solche Regeln lassen sich zunächst im "observe"-Modus testen und später in "deny" umschalten – ein sicherer Weg, um False Positives zu vermeiden.
Besonders stark zeigte sich Tetragon bei der Korrelation seiner Metrikdaten. Öffnet ein Prozess eine Verbindung, verknüpft das Tool automatisch Binary, Container-Image, Pod und Service-Account miteinander. So entsteht aus einem simplen Logeintrag eine nachvollziehbare Geschichte: Welcher Dienst, welches Release, welche Identität war beteiligt – und wie sieht die gewünschte Reaktion aus? Aktionen lassen sich direkt hinterlegen, vom Blockieren eines connect()-Syscalls bis zum Verhindern bestimmter Dateiöffnungen.
Sicherheit per YAML-Steuerung
Ein zentrales Element sind die Tracing Policies, die festlegen, welche Ereignisse Tetragon erfasst und wie es darauf reagiert. Sie folgen einem klaren, deklarativen Schema mit Parametern wie dem Beobachtungsziel ("exec", "open", "connect"), optionalen Selektoren (Namespace, Labels, Benutzer, Pfade) und Aktionen ("log", "alert", "deny").
Wer YAML beherrscht, kommt schnell zurecht. Beispielkataloge und Referenzen erleichtern den Einstieg, ein integrierter Linter prüft Syntaxfehler vor der Aktivierung. Für Teams mit Compliancevorgaben empfiehlt sich zudem, das Regelwerk in einem Git-Repository zu versionieren. So lassen sich Änderungen sauber nachverfolgen und gestaffelt ausrollen.
Tetragon unterstützt Administratoren beim Schreiben von Policies mit Attributfeldern, die exakt den beobachtbaren Systemparametern entsprechen. Pfadpräfixe, Prozessnamen, Nutzer-IDs oder Container-Labels lassen sich frei kombinieren. Fortgeschrittene Nutzer vermeiden so gezielt False Positives – etwa durch Ausnahmen für geplante Wartungsjobs.
Besonders relevant in regulierten Umgebungen ist der integrierte Redaction-Mechanismus, mit dem sensible Daten in Logs maskiert oder entfernt werden können. So lassen sich Datenschutzvorgaben auch bei tiefer Systembeobachtung einhalten.
Positiv fiel im Test zudem die Genauigkeit der Prozessketten auf. Tetragon dokumentiert mehrstufige Angriffsszenarien lückenlos – von initialem Zugriff über nachgeladene Tools bis zum Datenabfluss. Die Parent-Child-Beziehungen ergeben eine nachvollziehbare zeitliche Kette, die sich hervorragend für forensische Analysen eignet.
Auch im Netzwerkbereich überzeugt Tetragon. In Kombination mit Cilium und Hubble entstehen konsistente Flow-Daten und identitätsbezogene Visualisierungen. Aber selbst ohne Cilium arbeitet das Tool zuverlässig mit klassischen Angaben zu IP, Port und Protokoll. Für viele Umgebungen reicht das aus; wer jedoch Zero-Trust-Netzwerke aufbauen möchte, profitiert spürbar von der tieferen Integration.
Effektiver Schutz in realen Angriffsszenarien
Wie schlägt sich Tetragon unter realen Bedingungen? Im Test zeigte sich, dass das Werkzeug typische Angriffsformen in Kubernetes-Umgebungen zuverlässig erkennt und transparent darstellt. Ein klassisches Beispiel ist der Kryptominer, den sich Administratoren über ein Container-Image aus unsicherer Quelle einfangen. In einem kompromittierten Container lädt ein Skript per curl ein Programm nach, macht es ausführbar und startet es im Hintergrund.
Tetragon zeichnet diese komplette Sequenz auf – vom Download über den Schreibzugriff im Dateisystem bis zur Rechteänderung, Prozessausführung und der anschließenden Verbindung zu einem Mining-Pool. Mit einer passenden Policy lässt sich diese Kette nicht nur nachvollziehen, sondern bereits beim ersten Anzeichen unterbrechen – etwa, indem Prozessstarts unbekannter Binaries in Produktionsnamespaces generell blockiert werden.
Auch den Datenabfluss über DNS erkennt Tetragon zuverlässig. Angreifer nutzen dabei manipulierte Pods, um über massenhafte DNS-Abfragen interne Zonen auszuspähen. Tetragon erkennt solche Muster anhand ungewöhnlich häufiger Abfragen, langer Labels oder zufällig wirkender Hostnamen und ordnet sie dem verantwortlichen Pod zu. In Verbindung mit NetworkPolicies lässt sich der Ausweg dynamisch schließen, während forensische Daten bereits gesichert sind.
Schließlich deckt Tetragon auch den gefürchteten Container-Ausbruch ab. Absolute Sicherheit gibt es zwar nie, doch viele Ausbruchsversuche hinterlassen deutliche Spuren. Capability-Anhebungen, Mount-Operationen oder Zugriffe auf Hostpfade werden von Tetragon lückenlos protokolliert und erlauben so ein frühzeitiges Eingreifen – manuell oder automatisiert.
Analyse ohne Bremswirkung
Die Gretchenfrage bei Laufzeitsicherheit lautet: Wie teuer ist sie in Sachen Performance? Im Fall von Tetragon fällt die Antwort angenehm unspektakulär aus. Die eBPF-Programme hängen an Kernel-Hooks und liefern verdichtete Daten über Ring-Buffer in den Userspace, wo der Tetragon-Daemon sie asynchron verarbeitet. Kein Polling, keine ständigen Systemaufrufe – Ereignisse erscheinen nur, wenn sie tatsächlich auftreten.
Im Test führte das zu kaum messbarer Mehrlast: CPU-Anteile im niedrigen einstelligen Prozentbereich, Speicherbedarf pro Node im zweistelligen MByte-Bereich und Latenzen im Millisekunden-Feld.
Performance hängt allerdings auch von den Regeln ab. Breit gefasste Policies mit vielen Wildcards erzeugen deutlich mehr Events als präzise Selektoren. Auch der Export in externe SIEM-Systeme kann zur Lastquelle werden. Hier helfen Best Practices: Policies sollte der Admin so spezifisch wie möglich definieren. Vorgänge, die zwar erlaubt, aber sehr frequent sind, lassen sich durch gezieltes Downsampling auf das Wesentliche reduzieren. Ebenso empfiehlt es sich, Kernelpuffer für Lastspitzen zu dimensionieren, statt nur für den Alltag. Wer diese Hausaufgaben erledigt, wird Tetragon im Ressourcenmonitor kaum bemerken.
Selbst unter Stresstests blieb das Verhalten im Test stabil. Beim parallelen Start hunderter Pods, bei Rolling-Updates ganzer Deployments oder bei provozierten Fehlerbildern (CrashLoopBackOff, ImagePullBackOff) verlor Tetragon keine einzige Event-Benachrichtigung. Dashboards und Log-Pipelines blieben lückenlos.
Wichtig ist jedoch die Wahl der richtigen Hook-Typen in eBPF: Nicht jede Überwachung benötigt ein eigenes Programm auf jeden openat-Aufruf, von denen es oft Tausende gibt. Meist genügt der Fokus auf kritische Pfade wie Prozessstarts (execve), Capability-Änderungen oder Schreibzugriffe außerhalb bekannter Arbeitsverzeichnisse. Weniger ist hier oft mehr. Präzise Regeln sparen Ressourcen und Auswertungszeit.
Granulare Kontrolle statt blinder Reaktion
Tetragon zeigt im Ernstfall auch seine Zähne. Policies mit Aktionsanteil blockieren verdächtige Vorgänge in Echtzeit – vom Unterbinden einer Prozessausführung über das Verhindern bestimmter Dateiöffnungen bis hin zum Sperren kompletter Netzverbindungen.
Der entscheidende Vorteil liegt in der Granularität: Regeln lassen sich präzise auf Namespaces, Service-Accounts, Pfade oder Capabilities zuschneiden. So bleibt der reguläre Betrieb unbeeinträchtigt, während Angriffe zuverlässig gestoppt werden.
Für sensible Umgebungen empfiehlt sich ein gestufter Ansatz: erst beobachten, dann warnen, schließlich blockieren. Diese Eskalationslogik lässt sich in Tetragon problemlos abbilden. Im Zusammenspiel mit bestehenden Mechanismen wie Admission-Policies und Network-Policies entsteht so ein mehrlagiges Schutzkonzept: Admission verhindert Fehlkonfigurationen beim Rollout, Network-Policies regeln den Datenfluss – und Tetragon schützt die Laufzeit.
Robust im Alltag, aber kein Alleskönner
Im Dauertest überzeugte Tetragon mit Stabilität und berechenbarem Verhalten. Policies ließen sich kontrolliert ausrollen, Änderungen rückgängig machen und Tests gefahrlos zunächst im Beobachtungsmodus fahren. Diese schrittweise Einführung erleichtert den produktiven Einsatz erheblich. Ein oft unterschätzter Nebeneffekt: Wenn Entwickler und Security-Teams dieselben Daten und Logs sehen, verkürzt das Entscheidungswege und beschleunigt die Ursachenanalyse im Ernstfall spürbar.
Wie jedes Werkzeug hat auch Tetragon seine Grenzen. Es ersetzt weder Supply-Chain-Scanning noch Container-Image-Prüfungen oder dediziertes Alerting mit Eskalationslogik. Seine Stärke liegt eindeutig in der Laufzeitbeobachtung und -kontrolle und nicht in vorgelagerten oder organisatorischen Aspekten der IT-Sicherheit.
Dass der Tetragon-Daemon dabei erhöhte Rechte benötigt, ist technisch bedingt und auditrelevant, aber kaum vermeidbar. Ohne diese Privilegien könnte das Tool nicht tief genug in Kernelvorgänge eingreifen. Zugleich gilt: Wer in einer Umgebung bis auf Tetragon-Ebene kompromittiert wird, hat ohnehin ein gravierenderes Sicherheitsproblem.
Hilfreiche Community
Ein großes Plus von Tetragon ist die hervorragende Dokumentation und der aktive Austausch in der Community. Neben offiziellen Handbüchern finden sich zahlreiche Praxisbeispiele, Cheatsheets und Autovervollständigungen, die den Einstieg erleichtern.
Viele Unternehmen entwickeln daraus interne "Policy-Bibliotheken" für wiederkehrende Anwendungsfälle – etwa No-Shell-in-Prod, das Verbot riskanter Tools in Minimal-Containern oder Whitelists für Wartungsfenster. Diese Bibliotheken fördern konsistente Sicherheitsrichtlinien und erleichtern Audits erheblich.
Zwar bringt Tetragon selbst keine Unit-Tests für Policies mit, doch lassen sich Regeln problemlos in CI/CD-Pipelines einbinden und dort automatisiert verifizieren. Gerade diese Offenheit macht das Tool auch für komplexe DevSecOps-Umgebungen attraktiv.
Fazit
Tetragon löst ein Problem, das nahezu jeder Kubernetes-Administrator kennt: Es schafft Transparenz in der Laufzeit und macht sicherheitsrelevante Vorgänge sichtbar, bevor sie eskalieren. Das Werkzeug verbindet eBPF-Tempo mit Kubernetes-Verständnis und verwandelt Ereignisse in Erkenntnisse – aus einer IP-Adresse wird eine nachvollziehbare Spur, aus einem Prozessstart ein überprüfbarer Vorgang im Cluster.
Wer bereits Admission-Kontrollen, Network-Policies und Zugriffsverwaltung etabliert hat, erweitert mit Tetragon seine Sicherheitsarchitektur um eine leistungsfähige Laufzeitebene. Wer noch am Anfang steht, gewinnt ein präzises Frühwarnsystem. In jedem Fall ist Tetragon weniger Dashboard als Sensor- und Kontrollschicht mit echtem Mehrwert und damit ein Werkzeug, das in modernen Kubernetes-Umgebungen seinen festen Platz verdient.
(ln)
Einrichtung und Integration | 8 |
Laufzeitüberwachung | 9 |
Sicherheitsfunktionen | 7 |
Regelerstellung | 8 |
Performance und Stabilität | 10 |
|
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik |
|