Was Kubernetes-Audit-Logs nicht zeigen und was hilft

TL;DR. Das Kubernetes-Audit-Log sieht Requests an den API-Server und sonst nichts. Es sieht nicht, was in einem Container oder auf einem Node passiert, keine direkten Requests an Kubelet oder etcd, keine Änderungen im Cloud-IAM und keinen Netzwerkverkehr. Was es sieht, hängt von Ihrer Audit-Policy und der des Managed-Anbieters ab; manche Felder (Quell-IP, User Agent) beeinflusst der Client; und musterbasierte Regeln übersehen Angreifer, die sich wie Ihre Admins verhalten. Kombinieren Sie es mit Runtime-Erkennung, Node- und Container-Logs, Cloud-Audit-Logs und Flow-Logs.

Jeder Artikel dieser Serie argumentiert, dass das Audit-Log im Zentrum einer Kubernetes-Untersuchung steht. Dieser erklärt, wo es aufhört, damit ein „sauberes“ Ergebnis richtig gelesen wird.

Blinder Fleck 1: in Containern und auf Nodes

Der API-Server autorisiert und protokolliert den Request, der eine exec-Session öffnet, samt initialem Befehl, und leitet danach Bytes weiter, die er nicht protokolliert. Alles danach ist unsichtbar:

• Befehle, die in einer interaktiven Shell getippt werden;
• Prozesse, die die Anwendung nach einer RCE startet (Reverse Shell, heruntergeladenes Binary);
• Dateiänderungen im Container;
• alles, was nach einem Container-Escape auf dem Node geschieht: neue SSH-Schlüssel, Cron-Einträge, wiederverwendete Kubelet-Zugangsdaten, direkt über einen Runtime-Socket gestartete Container.

Das Audit-Log zeigt die Vorbereitung (einen privilegierten Container, einen hostPath auf /, ein exec mit chroot /host), nicht die Ausführung. Für den Rest brauchen Sie Runtime-Beweise: Falco oder ein EDR auf den Nodes, die eigenen Logs der Nodes (journald, Auth-Logs), Container-Logs und einen Disk-Snapshot betroffener Nodes.

Der Analyzer akzeptiert Falco-Alerts als JSON neben den Audit-Logs und legt beides auf eine Timeline; Alerts der Priorität Error und höher werden zu Findings.

Blinder Fleck 2: Wege am API-Server vorbei

Die Cloud-Seite hat ihren eigenen Audit-Trail: CloudTrail für EKS, Cloud Audit Logs für GKE, das Azure-Aktivitätsprotokoll für AKS. Die Schwesterseiten AWS Forensics, GCP Forensics und Azure Forensics decken sie ab.

Blinder Fleck 3: was die Policy nicht behalten hat

Was Sie erkennen können, ist durch das begrenzt, was protokolliert wurde:

• Level Metadata entfernt Request-Bodies. Das Anlegen eines DaemonSets ist sichtbar; ob es privilegiert war, welches Image es ausführte, welche Rolle ein Binding gewährte, nicht. Mehrere Erkennungen können schlicht nicht greifen. Der Leitfaden zur Audit-Policy zeigt, was Sie loggen sollten.
• Verwaltete Policies treffen eigene Entscheidungen: Die im EKS Best Practices Guide veröffentlichte EKS-Policy protokolliert keine Events; GKE schickt Lesezugriffe in standardmäßig deaktivierte Data-Access-Logs; die AKS-Kategorie kube-audit-admin lässt get und list weg. Siehe den Leitfaden zu EKS, GKE und AKS.
• Zustellung und Größe. EKS beschreibt die Zustellung der Control-Plane-Logs als „best effort“, und CloudWatch Logs begrenzt Einträge auf 1 MB, sehr große Objekte können also abgeschnitten werden.
• Aufbewahrung. Logs, die vor Beginn der Untersuchung abgelaufen sind, sind weg. Der Erstzugriff liegt oft vor der Erkennung.
• Abdeckung. In selbst betriebenen Clustern protokolliert jede API-Server-Instanz die Requests, die sie bedient hat; fehlt die Datei eines Control-Plane-Nodes, fehlt ein Teil der Geschichte.

Der Analyzer meldet, was er gelesen hat (Dateien, Zeitraum, Quellen, übersprungene und abgeschnittene Records), gerade damit diese Lücken sichtbar werden.

Blinder Fleck 4: Felder, denen Sie nicht ganz trauen können

• sourceIPs: Die Referenz der Audit-Events warnt, dass alle IPs außer der letzten per X-Forwarded-For vom Client gesetzt werden können. Hinter Load Balancern oder privaten Endpunkten kann die letzte IP eine Infrastrukturadresse sein.
• userAgent: vom Client geliefert. Ein sorgfältiger Angreifer sendet denselben Agent wie der Workload, dessen Token er gestohlen hat.
• Identität: Das Log nennt das Zugangsdatum, nicht die Person. Ein gestohlenes Token und sein legitimer Workload sehen bis auf den Kontext (Quelle, Uhrzeit, Verhalten) gleich aus.
• Impersonation: Lesen Sie user und impersonatedUser zusammen; wer nur eines berichtet, ordnet Aktionen falsch zu.

Blinder Fleck 5: Angreifer, die normal wirken

Erkennungsregeln erkennen Muster. Sie markieren einen Service Account, der kubectl exec ausführt, ein Binding an cluster-admin, ein Miner-Image. Sie markieren nicht:

• einen Angreifer, der mit gestohlenen Admin-Zugangsdaten genau das tut, was dieser Admin sonst auch tut;
• ein bösartiges Image mit gewöhnlichem Namen aus Ihrer üblichen Registry;
• langsam gelesene Daten, ein Secret pro Stunde, unter jeder Häufungsschwelle;
• eine Identität, deren Name einer Systemkomponente nachempfunden ist. Der Analyzer schließt Controller-Identitäten per Präfix aus; das ist nötig, um tausende False Positives zu vermeiden, bedeutet aber, dass ein Service Account, dessen Name in kube-system zu einem ausgeschlossenen Präfix passt, übersehen werden könnte. Prüfen Sie, wer dort Service Accounts anlegen darf.

Baselines helfen: erstes exec einer Identität seit 30 Tagen, erster Request aus einem neuen Netz, ein Workload außerhalb der Deployment-Pipeline. Solche Vergleiche brauchen eine Historie, die der Analyzer zwischen Sitzungen nicht speichert; Ihr SIEM schon.

Ein sauberes Urteil lesen

„Kein Hinweis auf Kompromittierung“ bedeutet, dass in den gelieferten Daten keine Regel gegriffen hat. Bevor Sie das akzeptieren, prüfen Sie:

1. Deckt der Zeitraum die fragliche Periode mit Puffer ab?
2. Wurden alle Control-Plane-Quellen einbezogen, und wurden Dateien übersprungen?
3. Protokolliert die Policy Bodies für Workload- und RBAC-Schreibzugriffe?
4. Wurden auf GKE und AKS Lesezugriffe überhaupt protokolliert?
5. Gibt es unabhängige Hinweise (Runtime-Alerts, Cloud-Rechnung, Node-Verhalten), die dem Ergebnis widersprechen?

Bleiben Zweifel, ziehen Sie eine erfahrene Incident-Response-Fachkraft hinzu und sichern Sie Runtime-Beweise, bevor die Nodes recycelt werden.

Die Beweislandkarte

FAQ

Protokollieren Kubernetes-Audit-Logs Befehle, die in einem Container ausgeführt werden?

Nur den initialen Befehl eines kubectl exec, der Teil der Request-URI ist. Alles, was danach in der Session getippt wird, und jeder Prozess, den die Anwendung selbst startet, ist für den API-Server unsichtbar und erfordert Runtime-Werkzeuge.

Wenn der Analyzer keinen Hinweis auf Kompromittierung meldet, ist der Cluster dann sauber?

Nicht unbedingt. Es bedeutet, dass in den gelieferten Logs keine Regel gegriffen hat. Fehlende Zeiträume, eine Audit-Policy nur mit Metadata, Aktivität auf Nodes oder in Containern und Angreifer, die normales Verhalten imitieren, können ohne Treffer bleiben.

Womit sollte ich Audit-Logs kombinieren?

Mit Runtime-Erkennung auf den Nodes (Falco oder ein EDR), Node- und Container-Logs, den Control-Plane-Audit-Logs des Cloud-Anbieters, Netzwerk-Flow-Logs und der Deployment-Historie aus CI oder GitOps.

Verwandte Artikel

• Kubernetes Incident Response mit Audit-Logs
• Kubernetes-Audit-Policy für die Forensik
• Privilegierte Pods und Anzeichen für Container-Escape