Folgen Wo Kubernetes-Audit-Protokolle gespeichert werden, hängt davon ab, wer Ihre Steuerungsebene betreibt. In einem selbstverwalteten Cluster sind sie eine JSON-lines-Datei auf dem Steuerungsebenenknoten, unter dem Pfad, auf den –audit-log-path verweist. Auf EKS gehen sie zu CloudWatch Logs, auf AKS zu einem Log Analytics-Arbeitsbereich oder Speicherkonto und auf GKE zu Cloud-Audit-Protokollen. Eine Sache gilt überall: Audit-Protokollierung muss eingeschaltet sein. In selbstverwalteten Clustern und EKS ist sie ausgeschaltet, bis sie jemand aktiviert.
Das Audit-Log verzeichnet jede Anfrage an die Kubernetes-API: wer kubectl exec in welchen Pod ausgeführt hat, wer welches Secret gelesen hat, wer sich selbst als Cluster-Admin gebunden hat. Prime Core hat 93 Erkennungsregeln für Kubernetes-Audit-Daten, die 220 MITRE ATT&CK-Techniken zugeordnet sind. Unter ihnen: Ausführung in laufende Container (T1609), Bereitstellung von bösartigen Containern (T1610) und Lesen von Anmeldeinformationen über die Container-API (T1552.007).
Bevor Sie anfangen
Ist es aktiviert?
| Plattform | Wo überprüft werden |
|---|---|
| Selbstverwaltet (kubeadm und ähnliche) | –audit-policy-file und –audit-log-path auf dem API-Server; mit kubeadm, in /etc/kubernetes/manifests/kube-apiserver.yaml |
| EKS | Cluster → Beobachtbarkeit → Steuerungsebene-Protokollierung, „Audit“-Protokolltyp |
| AKS | Diagnostikeinstellungen am Cluster, Kategorien kube-audit oder kube-audit-admin |
| GKE | Standardmäßig für Admin-Aktivität aktiviert; Datenzugriffsprotokollierung für Kubernetes ist opt-in |
Wenn es nicht eingeschaltet war, gibt es nichts aus der Vergangenheit zu exportieren, und der Rest dieses Leitfadens ist für das nächste Mal.
Details hängen von der Richtlinie ab. Auf Metadatenebene sehen Sie, wer was an welchem Objekt getan hat. Auf Anfrage- oder Anforderungsantwortebene sehen Sie auch die Inhalte, zum Beispiel die Pod-Spezifikation, die privilegiert: true angefordert hat. Wissen Sie, welche Sie haben, bevor Sie suchen.
Erwarten Sie Volumen. Controller und Dienstekonten kommunizieren ständig mit der API. Auf AKS lässt kube-audit-admin Lese-und Listen-Aufrufe weg, was die Größe vernünftig hält, aber auch Geheimnisse verbirgt.
Exportieren Sie es
Selbstverwalteter Cluster, auf einem Steuerungsebenenknoten:
# überprüfen Sie zuerst den Pfad
sudo grep -- '--audit-log-path' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo cat /var/log/kubernetes/audit/audit.log > k8s_audit.jsonl
Drehbare Dateien (von –audit-log-maxbackup) befinden sich daneben mit einem Zeitstempel im Namen. Schließen Sie sie ein, wenn das Fenster zurückreicht.
EKS, aus CloudWatch Logs:
aws logs filter-log-events --log-group-name /aws/eks/my-cluster/cluster
--log-stream-name-prefix kube-apiserver-audit
--start-time $(date -d '2026-10-19T00:00:00Z' +%s000) --end-time $(date -d '2026-10-20T00:00:00Z' +%s000)
--output json | jq -c '.events[].message | fromjson' > eks_audit_1019.jsonl
Jedes CloudWatch-Ereignis umschließt den Audit-Eintrag als Zeichenfolge; fromjson entpackt es. Die date -d Syntax ist GNU; auf macOS berechnen Sie die Millisekunden-Zeitstempel auf andere Weise.
AKS, aus Log Analytics (ressourcenspezifische Tabellen):
az monitor log-analytics query -w <workspace-id>
--analytics-query "AKSAuditAdmin | where TimeGenerated between (datetime(2026-10-19) .. datetime(2026-10-20))"
--output json > aks_audit_1019.json
GKE, aus Cloud Audit Logs:
gcloud logging read 'resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com" AND timestamp>="2026-10-19T00:00:00Z" AND timestamp<"2026-10-20T00:00:00Z"'
--project=my-project --format=json | jq -c '.[]' > gke_audit_1019.jsonl
Was zu suchen ist
| Anforderung | Warum es wichtig ist |
|---|---|
| Erstellen auf pods/exec (objectRef.subresource: exec) | Jemand hat eine Shell in einem laufenden Container geöffnet |
| Erstellen einer ClusterRoleBinding zu cluster-admin | Berechtigungsausweitung zur vollständigen Kontrolle |
| Abrufen oder Auflisten von Secrets durch eine ungewöhnliche Identität | Ernten von Anmeldeinformationen |
| Pods erstellt mit privilegiert, hostPath oder hostNetwork | Ein Schritt zur Flucht auf den Knoten |
| user.username: system:anonymous mit einer 2xx-Antwort | Anonymer Zugang, der nicht funktionieren sollte |
| Ausbrüche von 403 von einem Dienstkonto | Ein gestohlener Token, der seine Berechtigungen fühlt |
Hochladen, bereinigen und überprüfen in LogTotal
- Hochladen. Öffnen logtotal.com und die .jsonl-Datei ablegen.
- Bereinigen. [what gets masked: usernames, service account names, source IPs, namespaces, object names]. Look it over before you continue.
- Überprüfen.
Wenn es schiefgeht
| Symptom | Wahrscheinliche Ursache | Fix |
|---|---|---|
| Kein Audit-File auf der Steuerungsebene | API-Server hat keine Audit-Richtlinie konfiguriert | Erwartet; richten Sie es für die Zukunft ein |
| EKS-Protokollgruppe oder Audit-Streams fehlen | Der „Audit“-Protokolltyp der Steuerungsebene ist nicht aktiviert | Aktivieren Sie es für die Zukunft |
| Jede Zeile ist eine lange maskierte Zeichenfolge | CloudWatch-Einpackung | Mit fromjson entpacken, wie oben |
| Sie können sehen, wer einen Pod geändert hat, aber nicht wie | Richtlinie ist auf Metadatenebene | Erhöhen Sie die Ebene für sensible Ressourcen |
| Keine Secret-Lesevorgänge in AKS-Daten | kube-audit-admin schließt Abruf- und Listenoperationen aus | Sammeln Sie kube-audit, wenn Sie sie benötigen |
FAQ
Sind Container-Protokolle nicht ausreichend?
Nein. Container-Protokolle zeigen, was eine Anwendung gedruckt hat. Das Audit-Log zeigt, was Personen und Dienstkonten am Cluster gemacht haben. Unterschiedliche Fragen, unterschiedliche Logs.
Kann ich die Audit-Datei auf einem verwalteten Cluster lesen?
Nein. Auf EKS, AKS und GKE haben Sie keinen Zugriff auf die Steuerungsebene-Knoten. Der Logging-Dienst des Anbieters ist der einzige Weg.
