Das Audit-Log ist die chronologische, sicherheitsrelevante Spur aller Anfragen an den kube-apiserver: Wer hat wann welche Ressource mit welchem Ergebnis verändert? Es ist die wichtigste Quelle für Forensik, Compliance und Fehlersuche in Kubernetes-Clustern.
Standardmäßig ist das Audit-Log deaktiviert. Die Aktivierung erfolgt über zwei Flags des API-Servers: --audit-policy-file (Regelwerk) und --audit-log-path (Zieldatei). Auch die Entscheidungen der Admission Controller und ihre Webhook-Antworten sind darin dokumentiert.
Audit-Ebenen
Eine Audit-Policy besteht aus Regeln, die Ereignisse einer Ebene zuordnen:
- None: das Ereignis wird nicht protokolliert.
- Metadata: nur Metadaten (Benutzer, Zeitstempel, Ressource, Verb), keine Inhalte.
- Request: zusätzlich der vollständige Request-Body.
- RequestResponse: zusätzlich der Response-Body.
Die Regeln werden von oben nach unten ausgewertet, die erste passende Regel gewinnt. Üblich ist Metadata für die meisten Ressourcen und RequestResponse für sicherheitskritische Objekte wie RBAC-Rollen oder Secrets.
Stages und Backends
Jede Anfrage durchläuft Stages: RequestReceived, ResponseStarted, ResponseComplete und Panic. Über omitStages lassen sich laute, wenig informative Phasen ausblenden. Als Backends stehen der Log-Backend (Datei, Rotation über --audit-log-maxsize, --audit-log-maxbackup, --audit-log-maxage) und der Webhook-Backend (externer Empfänger über --audit-webhook-config-file) zur Verfügung.
Anfragen von Benutzern und ServiceAccounts – etwa über TokenRequest-Tokens – lassen sich so bis zur einzelnen API-Aktion zurückverfolgen. Auch Evictions bei Node Pressure, die in QoS-Reihenfolge ablaufen, erzeugen API-Ereignisse und erscheinen im Audit-Log.