TL;DR

• Kubernetes Audit Logging protokolliert alle API-Server-Anfragen mit vier Stufen: None, Metadata, Request und RequestResponse
• Audit Policies steuern granular, welche Ereignisse auf welcher Detailstufe erfasst werden
• Log-Backends (File und Webhook) leiten die Audit-Events an SIEM-Systeme wie Elasticsearch oder Splunk weiter
• Für Compliance-Anforderungen (ISO 27001, SOC 2) sind gezielte Audit-Regeln für Secrets, RBAC und Namespace-Änderungen essenziell

Kubernetes Audit Logging konfigurieren

Audit Logging gehört zu den wichtigsten Sicherheitsfunktionen in Kubernetes. Jede Anfrage an den API-Server wird protokolliert - von der Pod-Erstellung bis zum Secret-Zugriff. Ohne Audit Logging fehlt die Nachvollziehbarkeit, wer wann was im Cluster geändert hat.

Audit Stages und Levels

Der API-Server verarbeitet jede Anfrage in mehreren Phasen (Stages):

# Die vier Audit Stages:
# RequestReceived  - Anfrage beim API-Server eingegangen
# ResponseStarted  - Response-Header gesendet (nur bei watch/long-running)
# ResponseComplete - Response vollständig gesendet
# Panic            - Fehler im API-Server selbst

# Die vier Audit Levels:
# None             - Ereignis wird nicht protokolliert
# Metadata         - Request-Metadaten (User, Timestamp, Resource, Verb)
# Request          - Metadata + Request-Body
# RequestResponse  - Metadata + Request-Body + Response-Body

Die Wahl des richtigen Levels ist ein Kompromiss zwischen Detailtiefe und Speicherbedarf. RequestResponse für alle Ressourcen erzeugt enorme Datenmengen - hier braucht es gezielte Policies.

Audit Policy erstellen

Die Audit Policy definiert Regeln, die von oben nach unten ausgewertet werden. Die erste passende Regel gewinnt.

# /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Secrets: Zugriffe vollständig protokollieren
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    verbs: ["create", "update", "patch", "delete"]

  # RBAC-Änderungen: Request-Body mitloggen
  - level: Request
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]

  # Namespace-Lifecycle: Metadata reicht
  - level: Metadata
    resources:
      - group: ""
        resources: ["namespaces"]
    verbs: ["create", "delete"]

  # Health-Checks und Status ignorieren
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]

  - level: None
    nonResourceURLs:
      - "/healthz*"
      - "/readyz*"
      - "/livez*"

  # Alles andere: nur Metadata
  - level: Metadata
    omitStages:
      - "RequestReceived"

Diese Policy deckt die typischen Compliance-Anforderungen ab: Secret-Zugriffe werden vollständig erfasst, RBAC-Änderungen mit Body, und Health-Checks erzeugen keinen unnötigen Lärm.

API-Server mit Audit Logging starten

Die Audit Policy wird dem kube-apiserver als Flag übergeben. Bei kubeadm-Clustern editieren Sie das Static Pod Manifest:

# /etc/kubernetes/manifests/kube-apiserver.yaml (Auszug)
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
    - name: kube-apiserver
      command:
        - kube-apiserver
        ---audit-policy-file=/etc/kubernetes/audit-policy.yaml
        ---audit-log-path=/var/log/kubernetes/audit.log
        ---audit-log-maxage=30
        ---audit-log-maxbackup=10
        ---audit-log-maxsize=100
      volumeMounts:
        - name: audit-policy
          mountPath: /etc/kubernetes/audit-policy.yaml
          readOnly: true
        - name: audit-logs
          mountPath: /var/log/kubernetes
  volumes:
    - name: audit-policy
      hostPath:
        path: /etc/kubernetes/audit-policy.yaml
        type: File
    - name: audit-logs
      hostPath:
        path: /var/log/kubernetes
        type: DirectoryOrCreate

Nach dem Speichern startet kubelet den API-Server automatisch neu. Prüfen Sie den Status mit crictl pods | grep apiserver.

Log-Backends: File vs. Webhook

Kubernetes unterstützt zwei Audit-Backends, die auch parallel betrieben werden können.

Webhook-Backend konfigurieren

Für die direkte Weiterleitung an ein SIEM-System (z. B. Elasticsearch, Fluentd):

# /etc/kubernetes/audit-webhook-config.yaml
apiVersion: v1
kind: Config
clusters:
  - name: audit-webhook
    cluster:
      server: https://fluentd.monitoring.svc:24224/k8s-audit
      certificate-authority: /etc/kubernetes/pki/webhook-ca.crt
contexts:
  - name: audit-webhook
    context:
      cluster: audit-webhook
current-context: audit-webhook

Zusätzliche API-Server-Flags für das Webhook-Backend:

--audit-webhook-config-file=/etc/kubernetes/audit-webhook-config.yaml
--audit-webhook-batch-max-size=50
--audit-webhook-batch-max-wait=5s

Das Batching reduziert die Anzahl der HTTP-Requests an den Webhook-Endpunkt erheblich.

Audit-Events analysieren

Ein typisches Audit-Event im JSON-Format sieht so aus:

{
  "apiVersion": "audit.k8s.io/v1",
  "kind": "Event",
  "level": "RequestResponse",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/production/secrets",
  "verb": "create",
  "user": {
    "username": "developer@company.de",
    "groups": ["dev-team", "system:authenticated"]
  },
  "sourceIPs": ["10.0.1.42"],
  "objectRef": {
    "resource": "secrets",
    "namespace": "production",
    "name": "db-credentials"
  },
  "responseStatus": {
    "code": 201
  },
  "stageTimestamp": "2026-03-10T14:22:33.000000Z"
}

Nützliche jq-Abfragen für die Log-Analyse:

# Alle Secret-Zugriffe im Production-Namespace
jq 'select(.objectRef.resource == "secrets" and
    .objectRef.namespace == "production")' /var/log/kubernetes/audit.log

# Fehlgeschlagene Requests (403 Forbidden)
jq 'select(.responseStatus.code == 403)' /var/log/kubernetes/audit.log

# Änderungen durch einen bestimmten User
jq 'select(.user.username == "developer@company.de" and
    .verb != "get" and .verb != "list")' /var/log/kubernetes/audit.log

Compliance-Policy für ISO 27001

Für regulierte Umgebungen empfiehlt sich eine erweiterte Policy, die alle schreibenden Operationen auf kritischen Ressourcen vollständig erfasst:

Häufige Fehler vermeiden

Zu viel loggen: RequestResponse auf allen Ressourcen erzeugt Gigabytes pro Tag. Beschränken Sie dieses Level auf Secrets und sicherheitskritische Ressourcen.

Rotation vergessen: Ohne --audit-log-maxage und --audit-log-maxsize füllt sich die Festplatte. Setzen Sie beide Flags.

Webhook ohne Fallback: Wenn der Webhook-Endpunkt ausfällt, gehen Events verloren. Nutzen Sie File- und Webhook-Backend parallel.

FAQ

Was passiert, wenn keine Audit Policy definiert ist?

Ohne --audit-policy-file werden keine Audit-Events erzeugt. Der API-Server startet normal, aber es gibt keine Protokollierung von API-Anfragen.

Kann ich Audit Logging nachträglich aktivieren?

Ja. Bei kubeadm-Clustern ergänzen Sie die Flags im Static Pod Manifest. Der API-Server startet automatisch neu. Bei Managed Kubernetes (EKS, GKE, AKS) aktivieren Sie Audit Logging über die Cloud-Konsole.

Wie groß werden Audit-Logs?

Das hängt vom Cluster und der Policy ab. Ein mittelgroßer Cluster mit 50 Nodes erzeugt mit Metadata-Level etwa 500 MB pro Tag. Mit RequestResponse auf allen Ressourcen können es 5-10 GB sein.

Beeinflusst Audit Logging die API-Server-Performance?

Minimal. Das File-Backend schreibt asynchron. Das Webhook-Backend nutzt Batching. Nur bei extrem hoher Last (>1000 Requests/s) und RequestResponse-Level auf allem ist ein Einfluss messbar.

Welche Events sind für CKA/CKAD-Prüfungen relevant?

In der CKA-Prüfung können Audit Policies abgefragt werden. Konzentrieren Sie sich auf die Policy-Syntax, die vier Audit-Levels und die API-Server-Flags.