Kubernetes Audit Log 2026: was NIS2, KRITIS und DORA prüfen

Constantin Budin, Plattformberater bei Pexon Consulting | 11 Min. Lesezeit | 29.09.2026

TL;DR: Kubernetes Audit Log für Compliance

Ein Kubernetes Audit Log protokolliert jede Anfrage an den API-Server: wer, wann, welches Objekt, mit welchem Ergebnis. Für NIS2, KRITIS-Nachweise und DORA ist es die Quelle, die zeigt, wer Rechte und Workloads geändert hat. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) legt Policy, Aufbewahrung und Auswertung mit einem Owner fest.

Das Problem: Das Audit-Log läuft, aber niemand kann damit etwas beweisen

In Cluster-Reviews finden wir beim Audit-Log drei Zustände, und nur einer davon hält einer Prüfung stand. Im ersten Zustand ist es aus. Bei AKS ist das der Normalfall, bis jemand eine Diagnoseeinstellung anlegt. Im zweiten läuft es in einen Log-Analytics-Workspace mit der Standard-Aufbewahrung von 30 Tagen, und niemand hat je eine Abfrage darauf gestellt. Im dritten ist es aktiv, ausgeleitet, geschützt und hat einen Owner, der auf Alarme reagiert.

Der Unterschied zwischen dem zweiten und dritten Zustand ist kein Werkzeug. Es sind vier Entscheidungen: was protokolliert wird, wohin es geht, wie lange es bleibt und wer hinschaut. Genau diese vier Punkte fragen Prüfer ab, egal ob der Anlass NIS2, ein KRITIS-Nachweis oder eine DORA-Prüfung ist.

Der Zeitdruck ist real. Das NIS2-Umsetzungsgesetz gilt seit Dezember 2025 ohne Übergangsfrist, die Nachfrist des BSI für die Registrierung endete am 31.07.2026. Für Betreiber kritischer Anlagen erwartet das BSI laut seiner Seite KRITIS in Zahlen ab dem zweiten Quartal 2027 eine signifikante Zahl an Nachweisen. Wer einen Cluster in Energie, Wasser oder Gesundheit betreibt, sollte das Audit-Log vorher in den dritten Zustand bringen.

Was protokolliert ein Kubernetes Audit Log, und was nicht?

Ein Kubernetes Audit Log protokolliert Anfragen an die Kubernetes-API. Jeder Eintrag enthält Benutzer oder ServiceAccount, Quell-IP, Verb, Ressource, Namespace, Zeitstempel und Antwortcode. Was innerhalb eines Containers passiert, welche Prozesse auf einem Node laufen und was eine Anwendung in ihr eigenes Log schreibt, steht dort nicht.

Welche Details ein Eintrag enthält, bestimmt die Audit-Policy mit vier Stufen:

Für die Abgrenzung im Stack gilt: Das Audit-Log sagt, wer an der API etwas getan hat. Falco sagt, was ein Prozess im Container tut. Beides zusammen ergibt ein Bild, keines ersetzt das andere. Wie die Runtime-Seite aussieht, beschreiben wir im Beitrag zu Falco als Runtime-Erkennung.

Welche Kubernetes Audit Policy trägt eine Prüfung?

Eine prüffeste Audit-Policy protokolliert jede Änderung, jeden Zugriff auf Secrets und jede interaktive Sitzung in einem Pod, ohne den Inhalt von Secrets ins Log zu schreiben. Alles andere ist eine Frage von Kosten und Rauschen, nicht von Compliance.

Diese Policy nutzen wir als Startpunkt für selbst betriebene Cluster. Sie wird dem API-Server über --audit-policy-file übergeben:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  # Rauschen weglassen
  - level: None
    resources:
      - group: ""
        resources: ["events"]
  - level: None
    verbs: ["watch"]
    users: ["system:kube-proxy", "system:kube-scheduler"]
  # Secrets nie mit Inhalt protokollieren
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  # Interaktive Sitzungen in Pods
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach", "pods/portforward"]
  # RBAC-Änderungen mit Endzustand
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "rbac.authorization.k8s.io"
  # Alle anderen Änderungen mit Anfrage-Inhalt
  - level: Request
    verbs: ["create", "update", "patch", "delete", "deletecollection"]
  # Rest: nur Metadaten
  - level: Metadata

Der wichtigste Fehler, den wir in Policies für das Kubernetes Audit Log sehen: Secrets auf Request oder RequestResponse. Dann steht jedes Passwort, das ein Deployment anlegt, im Klartext im Log, und das Log wird selbst zum schützenswerten Datenbestand. Aus unserer Sicht gehört Metadata für Secrets in jede Policy, ohne Ausnahme.

Die Policy liegt versioniert in Git, nicht nur auf dem Control-Plane-Node. Ein Prüfer fragt nicht nur, was protokolliert wird, sondern seit wann und wer die Policy zuletzt geändert hat. Die Feldreferenz steht in der Kubernetes-Dokumentation unter Auditing.

Wie kommen AKS Audit Logs aus dem Cluster?

Bei AKS verwaltet Microsoft den API-Server, eine eigene Policy-Datei gibt es nicht. Die Audit-Events leiten Sie über eine Diagnoseeinstellung aus, und zwar in einen Log-Analytics-Workspace, einen Storage-Account oder einen Event Hub. Ohne diese Einstellung werden bei AKS keine Audit-Events gespeichert.

Zwei Kategorien stehen zur Wahl, und die Wahl hat Folgen:

• kube-audit enthält alle Anfragen, auch Lesezugriffe mit get und list. Landet in der Tabelle AKSAudit.
• kube-audit-admin lässt get und list weg und ist deutlich günstiger. Landet in der Tabelle AKSAuditAdmin.

Microsoft empfiehlt in der Doku zum Monitoring von AKS aus Kostengründen kube-audit-admin. Das reicht für Änderungen. Wer aber nachweisen muss, wer ein Secret gelesen hat, braucht kube-audit, weil das Lesen eines Secrets ein get ist. Unsere klare Empfehlung: kube-audit-admin im Workspace für die tägliche Auswertung, kube-audit zusätzlich in einen günstigen Storage-Account als Archiv.

az monitor diagnostic-settings create \
  --name aks-audit \
  --resource "$AKS_ID" \
  --workspace "$LAW_ID" \
  --export-to-resource-specific true \
  --storage-account "$ARCHIV_ID" \
  --logs '[{"category":"kube-audit-admin","enabled":true},
           {"category":"kube-audit","enabled":true},
           {"category":"guard","enabled":true}]'

Die erste Abfrage, die wir in jedem Workspace hinterlegen, zeigt alle Änderungen an Rollen und Rollenbindungen der letzten 30 Tage:

AKSAuditAdmin
| where TimeGenerated > ago(30d)
| where tostring(ObjectRef.resource) in ("clusterrolebindings", "rolebindings", "clusterroles", "roles")
| project TimeGenerated, Verb, Benutzer = tostring(User.username),
          Objekt = tostring(ObjectRef.name), Namespace = tostring(ObjectRef.namespace)
| order by TimeGenerated desc

Wie das Rollenmodell dahinter aussehen sollte, damit die Liste kurz bleibt, beschreibt unsere Seite zu Kubernetes RBAC fürs Audit.

Wohin müssen die Audit-Events, und warum reicht eine Senke selten?

Ein Audit-Log erfüllt drei Aufgaben, die selten ein System allein löst: Erkennung in Minuten, Nachweis über Jahre und Schutz vor Manipulation. Deshalb leiten wir die Events an mehrere Senken weiter, statt alles in einen Workspace zu schreiben.

1. SIEM (etwa Microsoft Sentinel): Regeln und Alarme in Minuten, zum Beispiel bei einer neuen ClusterRoleBinding auf cluster-admin. Hier entsteht die Angriffserkennung, die § 31 BSIG von KRITIS-Betreibern verlangt.
2. Unveränderlicher Speicher: ein Storage-Account mit Unveränderlichkeitsrichtlinie. Hier liegt der Nachweis, den auch ein Administrator mit vollen Rechten nicht nachträglich löschen kann.
3. Falco mit k8saudit-Plugin: optional, wenn Audit-Events und Runtime-Signale in denselben Regeln zusammenlaufen sollen.

Den Schutz vor Manipulation fordert DORA wörtlich. Artikel 12 der Delegierten Verordnung 2024/1774 verlangt Maßnahmen gegen Manipulation, Löschung und unbefugten Zugriff auf Protokolle, eine Erkennung von Protokollierungsausfällen und eine synchronisierte Uhrzeit. Den zweiten Punkt vergessen fast alle: Wenn das Audit-Log eine Stunde lang nichts liefert, muss jemand einen Alarm bekommen. Eine einfache Regel im SIEM, die bei null Events in 15 Minuten auslöst, schließt diese Lücke.

Was ein KRITIS-Nachweis 2027 und eine DORA-Prüfung am Audit-Log sehen wollen

Prüfer wollen kein Log sehen, sondern eine belegte Kette: Regel, Speicherfrist mit Begründung, Auswertung, Reaktion. Die Speicherfrist schreibt keine der drei Regelungen als feste Zahl vor. DORA sagt ausdrücklich, dass das Finanzunternehmen sie selbst festlegt, nach Geschäftszielen, Zweck der Aufzeichnung und Ergebnis der Risikobewertung. Wer eine Zahl ohne Begründung nennt, hat damit schon den ersten Befund.

Diese Belege legen wir für jeden Cluster in den Nachweisordner:

Die letzte Zeile ist der stärkste Beleg, den wir kennen. Ein Prüfer nimmt eine beliebige Änderung aus dem Ticketsystem, und Sie zeigen in zwei Minuten den passenden Eintrag im Audit-Log mit Benutzer und Uhrzeit. Gelingt das, sind die meisten Folgefragen erledigt.

Wie der gesamte NIS2-Nachweis für einen laufenden Cluster aussieht, beschreiben wir auf der Seite zum NIS2 Cluster Nachweis. Die Zuordnung zu ISO-27001-Controls steht auf unserer Seite zu ISO 27001 für den Kubernetes-Betrieb. Für Finanzunternehmen ergänzt der Beitrag DORA und AKS aus Sicht der Auditoren die Landing-Zone-Seite.

Häufig gestellte Fragen

Ist das Kubernetes Audit Log bei AKS standardmäßig aktiv?

Nein. AKS erzeugt die Audit-Events, speichert sie aber erst, wenn Sie eine Diagnoseeinstellung mit der Kategorie kube-audit oder kube-audit-admin anlegen. Ohne diese Einstellung gibt es für einen Vorfall keinen Nachweis, wer an der API etwas geändert hat.

Wie lange muss ich Kubernetes Audit Logs aufbewahren?

Keines der drei Regelwerke nennt eine feste Zahl. DORA verlangt, dass Sie die Frist selbst festlegen und begründen, NIS2 und KRITIS-Nachweise fragen nach einer nachvollziehbaren Regel. Wir empfehlen, die Frist aus der Risikobewertung abzuleiten und schriftlich festzuhalten, statt sie aus einem Blog zu übernehmen.

Reicht kube-audit-admin statt kube-audit?

Für Änderungen an Workloads und Rechten ja. Lesezugriffe auf Secrets fehlen darin, weil sie als get protokolliert werden. Wer diese nachweisen muss, leitet kube-audit zusätzlich in einen günstigen Speicher aus.

Was kostet ein Kubernetes Audit Log für Compliance?

Die Kosten entstehen in Log Analytics und im Speicher, abhängig von Clustergröße und gewählter Kategorie. Den größeren Aufwand machen Policy, Regeln und der Nachweisordner. Den Umfang für Ihren Cluster schätzen wir im unverbindlichen 45-Minuten-Cluster-Check, bevor jemand ein Angebot schreibt.

Ersetzt Falco das Kubernetes Audit Log?

Nein. Falco erkennt verdächtiges Verhalten von Prozessen im Container und auf dem Node. Das Audit-Log zeigt, wer über die API Rechte, Workloads oder Secrets angefasst hat. Für Angriffserkennung nach § 31 BSIG brauchen Sie beide Sichten.

Nächster Schritt

Verwandte Themen