Audit-Logs in EKS, GKE und AKS aktivieren und exportieren

TL;DR. Bei Managed Kubernetes können Sie die Audit-Policy nicht ändern, aber Sie entscheiden, ob das Audit-Log überhaupt aufbewahrt wird. EKS: den Control-Plane-Logtyp audit aktivieren; die Events landen in CloudWatch Logs, Log-Gruppe /aws/eks/<cluster>/cluster, Streams kube-apiserver-audit-*. GKE: Admin Activity (Schreibzugriffe) ist immer aktiv; Lesezugriffe, auch auf Secrets, gehen in die Data-Access-Logs, die Sie für die Kubernetes Engine API aktivieren müssen. AKS: eine Diagnoseeinstellung mit der Kategorie kube-audit anlegen (oder kube-audit-admin, das get und list weglässt). Als JSON exportieren und die Dateien in den Audit-Log-Analyzer ziehen.

Keine der drei Plattformen ist standardmäßig so konfiguriert, dass eine Untersuchung abgedeckt ist. Der schlechteste Zeitpunkt, das festzustellen, ist der Morgen nach einem Alert. Dieser Leitfaden zeigt, was Sie jetzt einschalten sollten und wie Sie die Daten herausholen, wenn Sie sie brauchen.

Amazon EKS

Aktivieren

Standardmäßig sendet EKS keine Control-Plane-Logs an CloudWatch; jeder Logtyp wird einzeln aktiviert, wie die EKS-Dokumentation zum Control-Plane-Logging beschreibt. In der Konsole: Cluster, Observability, Control plane logging, Manage logging, Audit einschalten (und Authenticator, das IAM-Principals auf Kubernetes-Benutzer abbildet). Per CLI:

aws eks update-cluster-config --region eu-west-1 --name my-cluster \
  --logging '{"clusterLogging":[{"types":["audit","authenticator"],"enabled":true}]}'

Es fallen die üblichen CloudWatch-Logs-Kosten für Ingestion und Speicherung an. Die Zustellung erfolgt „best effort“ und dauert in der Regel einige Minuten. Setzen Sie auf der Log-Gruppe eine Aufbewahrung, die zu Ihren Untersuchungsanforderungen passt.

Was die EKS-Policy protokolliert

AWS veröffentlicht die EKS-Audit-Policy im EKS Best Practices Guide. Forensisch wichtig:

• Secrets, ConfigMaps und Token-Reviews: nur Metadata.
• serviceaccounts/token: Request.
• Lesezugriffe (get, list, watch) auf die Core-Gruppe und bekannte API-Gruppen: Request; Schreibzugriffe: RequestResponse. Workload-Specs und RBAC-Bodies sind also verfügbar.
• events werden gar nicht protokolliert. Gelöschte Events tauchen nicht auf.
• CloudWatch-Logs-Einträge sind auf 1 MB begrenzt, während ein API-Request bis zu 1,5 MiB groß sein kann; sehr große Objekte können also abgeschnitten oder auf Metadaten reduziert werden.

Exportieren

Für einen kurzen Zeitraum genügt filter-log-events:

aws logs filter-log-events --log-group-name /aws/eks/my-cluster/cluster \
  --log-stream-name-prefix kube-apiserver-audit \
  --start-time 1789344000000 --end-time 1789430400000 > eks-audit.json

Die Zeiten sind Epoch-Millisekunden. Für Tage oder Wochen nutzen Sie einen Export-Task nach S3 (aws logs create-export-task) und laden die .gz-Objekte herunter: Jede Zeile ist ein Zeitstempel gefolgt vom JSON-Event. Als JSON exportierte Ergebnisse von CloudWatch Logs Insights funktionieren ebenfalls. Der Analyzer liest alle drei Varianten, auch gzip-Dateien und ganze Ordner.

IAM-Identitäten erscheinen im Audit-Log unter dem Benutzernamen, den Access Entries oder die ConfigMap aws-auth zuordnen. Um denselben Principal auf AWS-Seite zu verfolgen (CloudTrail, EKS-API, AssumeRole-Aufrufe), siehe AWS Forensics.

Google GKE

Zwei Logs, eines standardmäßig aus

GKE schreibt Kubernetes-Audit-Einträge in Cloud Audit Logs unter dem Ressourcentyp k8s_cluster. Die GKE-Audit-Policy verteilt sie so:

• Requests mit create, update und delete gehen ins Admin-Activity-Log, das immer aktiv ist und sich nicht abschalten lässt;
• get, list und updateStatus gehen ins Data-Access-Log, das laut der GKE-Seite zum Audit-Logging standardmäßig deaktiviert und nach Aktivierung kostenpflichtig ist.

Die Konsequenz ist hart: In einem GKE-Projekt mit Standardeinstellungen hinterlässt ein Angreifer, der alle Secrets per get liest, für diese Zugriffe keinen einzigen Audit-Eintrag. Aktivieren Sie die Data-Access-Logs für die Kubernetes Engine API unter IAM und Verwaltung, Audit-Logs, bevor Sie sie brauchen, und wägen Sie Volumen gegen Kosten ab.

Was die GKE-Policy protokolliert

Dieselbe Seite nennt: Requests auf Secrets, ConfigMaps und Token-Reviews werden auf Metadata protokolliert, Lesezugriffe allgemein auf Metadata, Schreibzugriffe allgemein auf RequestResponse. Workload-Specs und RBAC-Bindings sind bei Schreibzugriffen also sichtbar.

In Cloud Logging wird das Event umgeschrieben: protoPayload.methodName (zum Beispiel io.k8s.core.v1.pods.exec.create), protoPayload.resourceName, protoPayload.authenticationInfo.principalEmail, protoPayload.requestMetadata.callerIp und callerSuppliedUserAgent, dazu ein gRPC-Statuscode statt des HTTP-Codes. Der Analyzer bildet das auf Verb, Ressource, Subressource, Benutzer, IP und HTTP-Code zurück ab.

Exportieren

gcloud logging read \
  'resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com"' \
  --project=my-project --freshness=30d --format=json > gke-audit.json

Sie können Ergebnisse auch im Log-Explorer als JSON herunterladen oder für lange Zeiträume per Sink nach Cloud Storage oder BigQuery routen. BigQuery speichert die Nutzlast in protopayload_auditlog, Request- und Response-Bodies als JSON-Text; der Analyzer liest diese Zeilen, wenn Sie die Tabelle oder die Abfrageergebnisse als JSON oder zeilengetrenntes JSON exportieren (nicht CSV, Avro oder Parquet). Die Aufbewahrung hängt vom Log-Bucket ab: Admin-Activity-Logs landen im Bucket _Required, Data-Access-Logs in _Default, sofern Sie das Routing nicht geändert haben. Für die Google-Cloud-Seite eines Incidents (IAM, Service-Account-Keys, Compute) deckt GCP Forensics diese Logs ab.

Eine aktuelle Einschränkung des Analyzers: GKE-Impersonation-Details aus serviceAccountDelegationInfo werden noch nicht ausgewertet.

Azure AKS

Aktivieren

AKS sendet Control-Plane-Logs über eine Diagnoseeinstellung auf der Cluster-Ressource. Die AKS-Monitoring-Dokumentation beschreibt die Audit-Kategorien:

kube-audit brauchen Sie für Credential-Diebstahl, denn Secret-Zugriffe sind get und list. Microsoft weist darauf hin, dass diese Kategorie teuer werden kann; kube-audit-admin ist der günstigere Kompromiss, allerdings ohne Lesezugriffe. Ziele:

• Log Analytics, im ressourcenspezifischen Modus (Tabellen AKSAudit und AKSAuditAdmin) oder im älteren Azure-Diagnostics-Modus (Tabelle AzureDiagnostics, Event-JSON in log_s).
• Storage Account: stündliche PT1H.json-Blobs im Container insights-logs-kube-audit.
• Event Hubs: {"records": [...]}-Batches, meist von einem SIEM konsumiert.

Beispiel mit der Azure CLI, Ziel Log Analytics im ressourcenspezifischen Modus:

az monitor diagnostic-settings create --name aks-audit \
  --resource <aks-resource-id> --workspace <workspace-resource-id> \
  --export-to-resource-specific true \
  --logs '[{"category":"kube-audit","enabled":true}]'

Exportieren

Aus einem Storage Account laden Sie die PT1H.json-Blobs für den Zeitraum herunter (die Ordnerstruktur kodiert Datum und Stunde) und ziehen den ganzen Ordner in den Analyzer. Aus Log Analytics fragen Sie die Tabelle ab und speichern das Ergebnis als JSON statt als CSV:

az monitor log-analytics query --workspace <workspace-guid> \
  --analytics-query "AKSAudit | where TimeGenerated between (datetime(2026-09-13) .. datetime(2026-09-15))" \
  -o json > aks-audit.json

Die Ergebnisgröße von Abfragen ist begrenzt, teilen Sie lange Zeiträume also auf mehrere Abfragen auf. Der Analyzer liest AKSAudit-Zeilen (Spalten in PascalCase), AzureDiagnostics-Zeilen, Storage-Account-Blobs und Event-Hubs-Batches. Für Entra-ID-Anmeldungen und Azure-Aktivitäten rund um den Cluster siehe Azure Forensics.

Selbst betriebene Cluster

Bei kubeadm, k3s, RKE2 oder On-Premises-Distributionen gehören Policy und Dateien Ihnen. Kopieren Sie audit.log und die rotierten Dateien von jedem Control-Plane-Node (jeder API-Server protokolliert nur die Requests, die er selbst bedient hat), oder exportieren Sie sie dort, wohin Ihr Webhook oder Log-Shipper sie schickt. Der Artikel zur Audit-Policy enthält eine forensisch ausgerichtete Policy als Ausgangspunkt.

Bevor Sie analysieren

• Decken Sie den gesamten Zeitraum ab, beginnend Tage vor dem ersten verdächtigen Event.
• Lassen Sie die Originale unangetastet und arbeiten Sie mit Kopien; erfassen Sie Hashes, falls der Fall vor Gericht gehen könnte.
• Notieren Sie die Zeitzone. Audit-Zeitstempel sind UTC; Konsolen-Exporte nicht unbedingt.
• Suchen Sie nach Lücken. Ein Tag ganz ohne Events bedeutet meist eine Logging-Änderung, keinen ruhigen Cluster.

Öffnen Sie dann den Kubernetes-Audit-Log-Analyzer, ziehen Sie die Dateien oder Ordner hinein und folgen Sie der Schritt-für-Schritt-Analyse.

Verwandte Artikel

• Kubernetes-Audit-Policy für die Forensik
• Anatomie eines Kubernetes-Audit-Events
• Kubernetes Incident Response mit Audit-Logs