Kubernetes-Audit-Logs im Browser analysieren: Anleitung

TL;DR. Exportieren Sie die Audit-Logs Ihres API-Servers als JSON, ziehen Sie sie (Dateien, Ordner, ZIP oder .gz) in den Kubernetes-Audit-Log-Analyzer und lesen Sie die Seite von oben nach unten: gelesene Dateien, Urteil, Findings, Timeline, Entitäten, Checkliste zur Behebung, Event-Tabelle. Alles läuft lokal in einem Web Worker, der von Rust nach WebAssembly kompiliert ist; nichts wird hochgeladen. Behandeln Sie jedes Finding als Spur, die Sie mit den Verantwortlichen der Identität klären, nicht als Schlussfolgerung.

Diese Anleitung geht eine echte Triage-Sitzung mit dem Tool Panel für Panel durch und erklärt die Designentscheidungen, die Sie für die Interpretation kennen sollten.

Vorab: den richtigen Export besorgen

Der Analyzer liest nur JSON. Unterstützte Eingaben:

Gzip und ZIP (auch verschachtelt) werden als Stream gelesen, Exporte mit mehreren Gigabyte funktionieren also; die Grenze ist die Zeit, nicht der Speicher. CSV-Exporte aus Log Analytics oder Logs Insights werden noch nicht unterstützt: Exportieren Sie als JSON. Der Export-Leitfaden für EKS, GKE und AKS enthält die Befehle.

Wenn Sie erst üben möchten, klicken Sie auf Beispiel ausprobieren. Damit laden Sie einen klar gekennzeichneten fiktiven Incident, der im Walkthrough des fiktiven Incidents ausführlich besprochen wird.

Schritt 1: Dateien laden

Ziehen Sie Dateien oder einen ganzen Ordner auf die Ablagefläche oder nutzen Sie Dateien auswählen / Ordner auswählen. Eine Fortschrittszeile zeigt die gerade gelesene Datei, die verarbeiteten Bytes und die Zahl der Events. Sie können jederzeit abbrechen.

Unter der Haube liest ein Streaming-JSON-Splitter die Records einzeln, egal ob die Datei aus JSON-Zeilen, einem großen Array oder einer Cloud-Hülle besteht, und jeder Record wird in ein einheitliches Event-Modell normalisiert. Stages desselben Requests werden zu einem Event zusammengefasst, ein kubectl exec zählt also einmal, auch wenn die Policy sowohl ResponseStarted als auch ResponseComplete protokolliert.

Schritt 2: prüfen, was tatsächlich gelesen wurde

Bevor Sie einem Urteil vertrauen, scrollen Sie zu Gelesene Dateien und Übersprungene Dateien:

• Jede übersprungene Datei hat einen Grund: leer, nur Nullbytes (unvollständige Kopie), CSV-Export, kein JSON, beschädigtes gzip oder ZIP.
• Jede Datei zeigt Records, Events und Hinweise zu fehlerhaften, abgeschnittenen oder nicht erkannten Records.
• Die Statistik oben nennt die Zeitstempel Von und Bis und die erkannten Quellen (Audit-Log, EKS, GKE, AKS, Falco).

Deckt der Zeitraum nicht ab, was Sie interessiert, halten Sie an und exportieren Sie mehr. Zeigt eine Datei nur „andere Logtypen“, haben Sie vermutlich den falschen CloudWatch-Stream oder die falsche Log-Analytics-Tabelle exportiert.

Schritt 3: das Urteil lesen

Das Urteil ist eines von:

• Wahrscheinlich kompromittiert: mindestens eine kritische Erkennung oder drei verschiedene hohe Erkennungen.
• Verdächtige Aktivität: mindestens eine hohe Erkennung oder zwei verschiedene mittlere.
• Kein Hinweis auf Kompromittierung: nichts oberhalb dieser Schwelle.
• Keine Audit-Events gefunden: Die Dateien enthielten keine Kubernetes-Audit-Events.

Die Zeile Warum listet die Erkennungen, die das Urteil bestimmt haben. Die Schwellen sind bewusst einfach, damit Sie sie in einem Bericht erklären können. „Kein Hinweis auf Kompromittierung“ bedeutet nur, dass in den gelieferten Daten keine Regel gegriffen hat: Der Artikel zu den Grenzen erklärt, was sich in den Lücken verbergen kann.

Schritt 4: jedes Finding prüfen

Jedes Finding ist eine Erkennungsregel, die gegriffen hat, gruppiert nach beteiligter Identität oder beteiligtem Objekt (zum Beispiel ein Finding pro Service Account für exec, eines pro Image für Miner). Ein Finding zeigt:

• Regeltitel, Schweregrad, ATT&CK-Taktik und Technik-IDs;
• ersten und letzten Treffer sowie die Zahl der Events;
• beteiligte Objekte und Quell-IPs;
• bei Schwellenregeln (Häufungen von Secret-Lesezugriffen, auth can-i, 403) die ausgelöste Schwelle, etwa „10 oder mehr in 10 Min.“.

Klicken Sie auf Events anzeigen, um zur gefilterten Event-Tabelle zu springen. Stellen Sie dann die Frage, die jede Regel impliziert: Gibt es eine legitime Erklärung? Ein Admin, der während eines bekannten Ausfalls kubectl exec nutzt, ist in Ordnung; derselbe Admin um 3 Uhr morgens aus einem neuen Land nicht. Die Regeln sind Daten, eine geprüfte JSON-Datei im Projekt-Repository, und die Artikel zu den Erkennungen erklären jede Familie.

Schritt 5: der Timeline folgen

Die Incident-Timeline listet markierte Events chronologisch. Fett gedruckte Zeilen zeigen, wo eine Erkennung zum ersten Mal greift: Bei einem echten Einbruch lesen sie sich wie die Kapitel des Angriffs (Zugriff, Aufklärung, Credential-Diebstahl, Eskalation, Persistenz, Schaden). Aktivieren Sie Events niedriger Schwere einbeziehen, um Kontext wie neue ClusterRoleBindings oder Images aus unüblichen Registries hinzuzufügen.

Wechseln Sie mit dem Zeitzonen-Schalter zwischen UTC und Lokal. Bleiben Sie für alles, was Sie notieren, bei UTC.

Schritt 6: über Entitäten pivotieren

Das Panel Entitäten beantwortet „wer hat was von wo getan“:

• Benutzer & Service Accounts, mit Zahl der Events, markierten und verweigerten Requests, erstem und letztem Auftreten;
• Quell-IPs, mit einem Badge öffentlich für Internetadressen;
• Namespaces, Pods (mit Zahl der exec-Sessions), Images und User Agents.

Ein Klick auf einen Wert filtert die Event-Tabelle darauf. Der klassische Pivot: vom markierten Service Account zu seinen Quell-IPs, dann von diesen IPs zu allen anderen Identitäten, die sie verwendet haben. Eine IP, die sich in derselben Minute als zwei verschiedene Service Accounts authentifiziert, ist eine Person mit zwei gestohlenen Tokens.

Schritt 7: in die Events eintauchen

Die Event-Tabelle filtert nach Erkennung, Mindestschweregrad, nur markierten Events und Freitext (Benutzer, IP, Objekt, Befehl). Ein Klick auf eine Zeile öffnet das Detailblatt: Benutzer und Gruppen, impersonierter Benutzer, Quell-IPs, User Agent, Verb und Objekt, Request-URI, exec-Befehl, Images, Response-Code, Autorisierungsentscheidung und -grund, Stage und Level, Audit-ID, Quelldatei und, falls protokolliert, der Request-Body.

Bei Exporten bis 50 000 Events bleibt jedes Event durchsuchbar. Darüber behält die Tabelle nur markierte Events, während Zähler, Entitäten und Findings weiterhin die gesamte Eingabe abdecken.

Schritt 8: exportieren und beheben

• CSV exportiert die gefilterten Events (Zellen, die als Tabellenformeln interpretiert werden könnten, werden neutralisiert).
• JSON-Report exportiert Urteil, Findings, Entitäten und Behebungsliste für Ihre Fallakte.

Die Checkliste zur Behebung wird aus den Findings erzeugt und nach Dringlichkeit sortiert: zuerst Beweise sichern und eingrenzen, dann Tokens widerrufen, Bindings entfernen, bösartige Workloads löschen, Nodes neu aufbauen, Secrets rotieren und härten. Abhaken speichert nichts, übertragen Sie die Liste also in Ihr Ticketsystem. Der Block Nächste Schritte verlinkt nur auf offizielle Empfehlungen von kubernetes.io und den Cloud-Anbietern.

Häufige Stolperfallen

• Logs nur eines Control-Plane-Nodes. Jede API-Server-Instanz protokolliert, was sie bedient hat. Sammeln Sie alle.
• Policy nur mit Metadata. Privilegierte Pods und cluster-admin-Bindings lassen sich nur mit Request-Bodies erkennen; siehe den Leitfaden zur Audit-Policy.
• Plattformkomponenten markiert. Die Regeln schließen Kubernetes-Controller und gängige Cloud-Agents aus; Ihre eigenen Operatoren (GitOps, Backup, Service Mesh) können dennoch exec- oder DaemonSet-Findings auslösen. Prüfen Sie sie und vermerken Sie sie als bekannt legitim.
• Zu kurzer Zeitraum. Liegt das erste markierte Event ganz am Anfang des Exports, exportieren Sie ältere Daten.

Verwandte Artikel

• Kubernetes Incident Response mit Audit-Logs
• Fiktiver Incident: vom Dashboard-Token zum Krypto-Miner
• Audit-Logs von EKS, GKE und AKS aktivieren und exportieren