Kubernetes Incident Response mit API-Server-Audit-Logs

TL;DR. Bei einem Kubernetes-Incident ist das Audit-Log des API-Servers Ihre wichtigste Quelle: Jedes kubectl exec, jeder Secret-Zugriff, jedes neue Binding und jeder neue Workload lief über den API-Server und kann mit wer, woher, was und ob erlaubt protokolliert werden. Sichern Sie zuerst die Logs und beantworten Sie dann fünf Fragen der Reihe nach: welche Identität, seit wann, was wurde angefasst, was wurde zurückgelassen, und was ist noch erreichbar. Der kostenlose Audit-Log-Analyzer im Browser liefert ein erstes Urteil, auf MITRE ATT&CK gemappte Findings und eine Timeline, ohne dass etwas hochgeladen wird; der Rest dieses Leitfadens erklärt, was hinter jedem Schritt steckt.

Kubernetes-Incidents beginnen selten mit einem Alert, der „Ihr Cluster ist kompromittiert“ meldet. Sie beginnen mit einer Cloud-Rechnung, die sich verdoppelt, einem Node bei 100 % CPU, einer Falco-Regel, die niemand getunt hat, oder einem Service-Account-Token in einem öffentlichen Repository. Dann müssen Sie schnell wissen, ob jemand den Cluster tatsächlich benutzt hat und wofür.

Warum das Audit-Log im Zentrum der Untersuchung steht

Jede Änderung an einem Cluster und die meisten Lesezugriffe laufen über den Kubernetes-API-Server. Das Kubernetes-Auditing zeichnet diese Requests als strukturierte Events auf: authentifizierter Benutzer und Gruppen, Quell-IPs, User Agent, Verb, Zielressource, Namespace, Name und Subressource, Response-Code und, je nach Audit-Level, die Request- und Response-Bodies.

Damit ist es das einzige Log, das den Großteil der Arbeit eines Angreifers über die Control Plane abdeckt:

Was es nicht zeigt, ist genauso wichtig: Befehle, die in einer bereits geöffneten Shell getippt werden, Prozesse, die nach einem Ausbruch auf einem Node gestartet werden, oder Traffic zwischen Pods. Der Artikel zu den Grenzen behandelt diese Lücken und die Runtime-Quellen, die sie schließen.

Schritt 0: sichern, bevor Sie etwas anfassen

Der Reflex ist, den bösartigen Pod zu löschen. Halten Sie ein paar Minuten inne.

1. Exportieren Sie die Audit-Logs für den gesamten Zeitraum und speichern Sie sie außerhalb des Clusters. Auf Managed-Plattformen liegen sie in CloudWatch Logs (EKS), Cloud Logging (GKE) oder Azure Monitor (AKS); der Export-Leitfaden für EKS, GKE und AKS enthält die genauen Befehle. Prüfen Sie die Aufbewahrung: Logs, die morgen ablaufen, sichern Sie zuerst.
2. Sichern Sie die Specs verdächtiger Objekte mit kubectl get <kind> <name> -o yaml, bevor Sie sie löschen: DaemonSets, CronJobs, Pods, ClusterRoleBindings, ServiceAccounts.
3. Erstellen Sie Snapshots der Disks betroffener Nodes, wenn Sie einen Container-Escape vermuten. Ein ersetzter Node nimmt seine Beweise mit.
4. Notieren Sie, was Sie bereits getan haben, mit Uhrzeit in UTC. Ihre eigenen kubectl-Befehle erscheinen im selben Audit-Log.

Die AWS-Empfehlungen zu Incident Response und Forensik für EKS und Googles Maßnahmen gegen Sicherheitsvorfälle in GKE folgen derselben Reihenfolge: isolieren, sichern, dann beheben.

Schritt 1: ein erster Blick in die Logs

Ein Cluster erzeugt viel Audit-Rauschen: Kubelets erneuern Leases, Controller reconcilen, Monitoring-Agents listen alle paar Sekunden Pods. Rohe JSON-Zeilen zu lesen ist jenseits einiger tausend Events nicht realistisch.

Ziehen Sie den Export in den Kubernetes-Audit-Log-Analyzer. Er normalisiert rohe audit.k8s.io/v1-JSON-Zeilen und die Exportformate von EKS, GKE und AKS in ein einheitliches Event-Modell, wendet 28 geprüfte Erkennungsregeln an und liefert:

• ein Urteil: „Wahrscheinlich kompromittiert“, sobald mindestens eine kritische Regel oder drei verschiedene hohe Regeln greifen, „Verdächtige Aktivität“ bei einer hohen oder zwei mittleren Regeln, sonst „Kein Hinweis auf Kompromittierung“;
• Findings, gruppiert nach Identität oder Image, jeweils mit Schweregrad, ATT&CK-Technik-ID und Behebungsschritten;
• eine Incident-Timeline, in der das erste Auftreten jeder Regel hervorgehoben ist;
• einen Entitäten-Pivot (Benutzer und Service Accounts, Quell-IPs, Namespaces, Pods, Images, User Agents).

Alles läuft im Browser-Tab mit WebAssembly; die Dateien werden nie hochgeladen. Die Schritt-für-Schritt-Anleitung geht jedes Panel durch.

Ein Urteil ohne Hinweis auf Kompromittierung ist kein Beweis für Sicherheit. Es bedeutet, dass in den gelieferten Daten keine Regel gegriffen hat, und diese Daten hängen stark von Ihrer Audit-Policy ab.

Schritt 2: die fünf Fragen beantworten

Welche Identität?

Beginnen Sie beim Finding mit dem höchsten Schweregrad und notieren Sie user.username. Ein Service Account (system:serviceaccount:<namespace>:<name>), der mit kubectl/ oder curl/ als User Agent oder von einer öffentlichen IP aus genutzt wird, ist fast immer ein Token, das seinen Pod verlassen hat. Eine menschliche Identität, die etwas Ungewöhnliches tut, verdient einen Anruf beim Verantwortlichen, bevor Sie Schlüsse ziehen.

Denken Sie daran, dass sourceIPs zuerst Proxy-Header auflistet; die Referenz der Audit-Events warnt, dass alle Adressen außer der letzten vom Client gesetzt werden können.

Seit wann?

Filtern Sie die Events auf diese Identität und ihre Quell-IPs und suchen Sie den ältesten Request. Angreifer betreiben meist Aufklärung (/version, /api, Discovery-Aufrufe, auth can-i), bevor sie laut werden. Liegt das früheste Event ganz am Anfang Ihres Exports, ist der Export zu kurz: Gehen Sie weiter zurück.

Was wurde angefasst?

Listen Sie alle Verben und Ressourcen der Identität auf. Gelesene Secrets sind am dringendsten: Jedes ist ein Zugangsdatum, das rotiert werden muss, und manche (Cloud-Keys, CI-Tokens, Registry-Zugangsdaten) reichen über den Cluster hinaus. Siehe Secret-Zugriffe und Diebstahl von Service-Account-Tokens.

Was wurde zurückgelassen?

Suchen Sie nach Schreibzugriffen: Workloads, CronJobs, DaemonSets, ServiceAccounts, (Cluster)RoleBindings, Rollen, Webhooks und neue Tokens, ausgestellt über TokenRequest. Jedes davon ist ein Weg zurück, nachdem Sie das erste Zugangsdatum widerrufen haben. Der Artikel zur RBAC-Eskalation behandelt die Binding-Seite, der Artikel zu privilegierten Pods die Node-Seite.

Was ist noch erreichbar?

Ein cluster-admin, der per exec in einen privilegierten Pod gelangt, konnte Node-Zugangsdaten, Cloud-Instanzrollen und jedes gemountete Secret lesen. Weiten Sie den Blick über den Cluster hinaus: Cloud-Account (CloudTrail, Cloud Audit Logs, Azure Activity Log), CI-System, Registry. Für die Cloud-Seite decken die Schwesterseiten AWS Forensics, GCP Forensics und Azure Forensics diese Logs ab.

Schritt 3: eindämmen, bereinigen, wiederherstellen

Die Reihenfolge zählt, weil manche Schritte andere entwerten.

1. Kappen Sie den aktuellen Zugriff des Angreifers. Entfernen Sie die bösartigen Bindings, löschen Sie kompromittierte Service Accounts und legen Sie sie neu an (ein per TokenRequest ausgestelltes Token bleibt bis zum Ablauf gültig, sofern nicht der Service Account oder das gebundene Objekt gelöscht wird, wie die Dokumentation zu Service Accounts erklärt), und schränken Sie ein, wer den API-Endpunkt erreicht.
2. Entfernen Sie die Persistenz. Löschen Sie bösartige DaemonSets, CronJobs, Jobs und Pods, nachdem Sie ihre Specs gesichert haben, und suchen Sie in allen Namespaces nach Kopien.
3. Bauen Sie Nodes neu auf, auf denen privilegierte oder hostmountende Pods liefen. Cordon, Drain, ersetzen; Kubelet- und Cloud-Instanz-Zugangsdaten rotieren.
4. Rotieren Sie jedes gelesene Secret.
5. Schließen Sie den Einstiegspunkt: exponiertes Dashboard, geleakte kubeconfig, überprivilegiertes Token, anonymer Zugriff.
6. Härten und überwachen: Pod Security Admission auf jedem Namespace, RBAC nach dem Least-Privilege-Prinzip, Audit-Logs außerhalb des Clusters aufbewahrt. Der Kubernetes Hardening Guide von NSA und CISA und die Kubernetes-Sicherheitscheckliste sind gute Grundlagen.

Die Checkliste zur Behebung im Analyzer folgt dieser Reihenfolge und listet nur die Schritte, die zu Ihren tatsächlichen Findings passen.

Findings auf ATT&CK mappen, nicht auf Tools

Der Bericht schreibt sich leichter, wenn jedes Finding eine Technik-ID trägt. Die MITRE ATT&CK Containers Matrix deckt die üblichen Schritte ab: T1609 Container Administration Command für exec, T1610 Deploy Container, T1611 Escape to Host, T1552.007 Container API für Secret-Diebstahl, T1528 Steal Application Access Token, T1098.006 Additional Container Cluster Roles, T1053.007 Container Orchestration Job, T1496 Resource Hijacking. Jede Erkennungsregel des Analyzers trägt diese IDs, der Export ist also berichtsfertig.

Ein realistisches End-to-End-Beispiel

Wenn Sie all das an konkreten Events sehen möchten: Der Walkthrough eines fiktiven Incidents folgt einem exponierten Dashboard-Token bis zu cluster-admin und einem Krypto-Miner in 15 Minuten Audit-Events. Dieselben Daten stecken hinter dem Button „Beispiel ausprobieren“ auf der Analyzer-Seite.

FAQ

Was ist der erste Schritt, wenn ein Kubernetes-Cluster kompromittiert sein könnte?

Beweise sichern, bevor Sie etwas ändern: die Audit-Logs des API-Servers für den gesamten Zeitraum exportieren, ihre Aufbewahrung verlängern und die Specs verdächtiger Workloads und Bindings sichern. Wer zuerst einen Pod oder ein Binding löscht, zerstört Kontext, den er später zur Eingrenzung braucht.

Reichen Kubernetes-Audit-Logs aus, um einen Einbruch zu untersuchen?

Sie sind die wichtigste Aufzeichnung dessen, was über die Kubernetes-API passiert ist, sehen aber keine Prozesse in Containern oder auf Nodes. Ergänzen Sie sie um Runtime-Alerts, Node- und Container-Logs sowie die Control-Plane-Logs Ihres Cloud-Anbieters.

Wie weit zurück sollte ich Audit-Logs exportieren?

Beginnen Sie einige Tage vor dem ersten bekannten verdächtigen Event und gehen Sie weiter zurück, sobald Sie eine frühere Spur derselben Identität oder Quell-IP finden. Der Erstzugriff liegt oft vor dem lauten Teil eines Angriffs.