Kubernetes Security Audit: Die komplette Checkliste

TL;DR

Ein Kubernetes Security Audit prüft systematisch fünf Bereiche: CIS Benchmark Compliance (kube-bench), RBAC-Konfiguration, Network Policies, Secret-Verschlüsselung und Container-Image-Sicherheit (Trivy). Starten Sie mit kube-bench für einen schnellen Überblick, priorisieren Sie dann Findings nach Kritikalität. Dieser Guide liefert Befehle, YAML-Configs und eine priorisierte Checkliste.

Die meisten Kubernetes-Cluster haben Sicherheitslücken, die sich mit einem strukturierten Audit finden lassen. Beginnen Sie mit dem CIS Benchmark Scan -- er zeigt in wenigen Minuten die kritischsten Probleme:

# kube-bench als Job im Cluster ausführen
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Ergebnisse anzeigen
kubectl logs job/kube-bench

# Oder lokal auf einem Node ausführen
kube-bench run --targets master,node,etcd,policies

kube-bench prüft Ihren Cluster gegen den CIS Kubernetes Benchmark und gruppiert Findings in PASS, FAIL und WARN. Konzentrieren Sie sich zuerst auf die FAIL-Ergebnisse.

Bereich 1: CIS Benchmark mit kube-bench

Der CIS Kubernetes Benchmark definiert über 200 Sicherheitsprüfungen für Master-Nodes, Worker-Nodes, etcd und Policies. kube-bench automatisiert diese Prüfungen.

Typische Findings und Fixes

Bei Managed Kubernetes (EKS, AKS, GKE) sind viele Master-Checks nicht anwendbar, da der Cloud-Provider die Control Plane verwaltet. Führen Sie kube-bench mit --targets node,policies aus.

# Nur Worker-Nodes und Policies prüfen (für Managed K8s)
kube-bench run --targets node,policies

# Ergebnisse als JSON für automatisierte Auswertung
kube-bench run --json | jq '.Controls[] | {id: .id, text: .text, fail: [.tests[].results[] | select(.status == "FAIL")]}'

Bereich 2: RBAC-Review

Überprivilegierte Rollen und ServiceAccounts sind das häufigste Sicherheitsproblem in Kubernetes-Clustern. Ein RBAC-Audit deckt auf, wer mehr Rechte hat als nötig.

# Alle ClusterRoleBindings mit cluster-admin Rolle finden
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name + " -> " + (.subjects[]? | .kind + "/" + .name)'

# ServiceAccounts mit Wildcard-Berechtigungen identifizieren
kubectl get clusterroles -o json | \
  jq -r '.items[] | select(.rules[]?.verbs[]? == "*") | .metadata.name'

# Berechtigungen eines spezifischen ServiceAccounts prüfen
kubectl auth can-i --list --as=system:serviceaccount:default:default

RBAC-Audit Checkliste

Prüfen Sie diese Punkte systematisch:

• Gibt es ClusterRoleBindings zu cluster-admin außer für den Admin-User?
• Nutzen Anwendungen den default-ServiceAccount statt eigener Accounts?
• Haben ServiceAccounts Wildcard-Berechtigungen (* bei verbs oder resources)?
• Ist automountServiceAccountToken: false bei Pods gesetzt, die kein API-Zugriff brauchen?
• Werden Rollen auf Namespace-Ebene (Role) statt Cluster-Ebene (ClusterRole) definiert?

Jede Anwendung sollte einen dedizierten ServiceAccount mit minimalen Rechten haben. Hier ein Beispiel:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: webapp-sa
  namespace: produktion
automountServiceAccountToken: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: webapp-role
  namespace: produktion
rules:
  - apiGroups: ['']
    resources: ['configmaps']
    resourceNames: ['webapp-config']
    verbs: ['get', 'watch']

Beachten Sie resourceNames: Der ServiceAccount darf nur eine spezifische ConfigMap lesen, nicht alle im Namespace.

Bereich 3: Network Policies verifizieren

Network Policies existieren oft auf dem Papier, werden aber nicht durchgesetzt -- entweder weil das CNI-Plugin sie nicht unterstützt oder weil Default-Deny fehlt.

# Prüfen ob ein CNI mit NetworkPolicy-Support installiert ist
kubectl get pods -n kube-system -l k8s-app=calico-node 2>/dev/null && echo "Calico: OK" || echo "Calico: nicht gefunden"
kubectl get pods -n kube-system -l k8s-app=cilium 2>/dev/null && echo "Cilium: OK" || echo "Cilium: nicht gefunden"

# Namespaces OHNE NetworkPolicies finden
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  count=$(kubectl get networkpolicies -n $ns --no-headers 2>/dev/null | wc -l)
  if [ "$count" -eq 0 ]; then
    echo "WARNUNG: $ns hat keine NetworkPolicies"
  fi
done

Jeder Produktions-Namespace braucht mindestens eine Default-Deny-Policy. Ohne diese Policy kann jeder Pod mit jedem anderen Pod im Cluster kommunizieren.

Bereich 4: Secret-Verschlüsselung prüfen

Kubernetes Secrets sind standardmäßig nur Base64-kodiert -- nicht verschlüsselt. Prüfen Sie, ob Encryption at Rest konfiguriert ist.

# Prüfen ob EncryptionConfiguration aktiv ist
kubectl get pods -n kube-system -l component=kube-apiserver -o jsonpath='{.items[0].spec.containers[0].command}' | tr ',' '\n' | grep encryption

# Secret auslesen und prüfen ob es im etcd verschlüsselt wäre
kubectl create secret generic audit-test --from-literal=test=geheim -n default
kubectl get secret audit-test -o jsonpath='{.data.test}' | base64 -d
kubectl delete secret audit-test

Bei Managed Kubernetes ist etcd-Verschlüsselung meist standardmäßig aktiv. Prüfen Sie die Dokumentation Ihres Providers:

Bereich 5: Image-Vulnerability-Scanning mit Trivy

Veraltete oder verwundbare Container-Images sind ein häufiger Angriffsvektor. Trivy scannt Images auf bekannte CVEs.

# Einzelnes Image scannen
trivy image --severity HIGH,CRITICAL nginx:1.25

# Alle Images im Cluster scannen
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' | sort -u | while read image; do
  echo "=== Scanning: $image ==="
  trivy image --severity CRITICAL --quiet "$image"
done

# Trivy als Kubernetes Operator für kontinuierliches Scanning
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/trivy-operator/main/deploy/static/trivy-operator.yaml

Der Trivy Operator erstellt automatisch VulnerabilityReports für jedes Deployment:

# Vulnerability-Reports im Cluster abfragen
kubectl get vulnerabilityreports -A -o wide

# Kritische Findings filtern
kubectl get vulnerabilityreports -A -o json | \
  jq -r '.items[] | select(.report.summary.criticalCount > 0) | .metadata.namespace + "/" + .metadata.name + ": " + (.report.summary.criticalCount | tostring) + " CRITICAL"'

Priorisierte Security-Audit-Checkliste

Arbeiten Sie diese Checkliste von oben nach unten ab. Die Reihenfolge entspricht dem Risiko:

Priorität 1 -- Sofort beheben

• kube-bench FAIL-Findings auf Master und Worker Nodes behoben
• Keine ClusterRoleBindings zu cluster-admin für Anwendungs-ServiceAccounts
• etcd-Verschlüsselung für Secrets aktiviert
• Keine Container mit privileged: true in Produktion
• Keine Images mit CRITICAL CVEs im Cluster

Priorität 2 -- Innerhalb einer Woche

• Default-Deny NetworkPolicies in allen Produktions-Namespaces
• Eigene ServiceAccounts pro Anwendung (nicht default)
• automountServiceAccountToken: false wo kein API-Zugriff nötig
• Pod Security Standards auf mindestens baseline
• Trivy-Scanning in CI/CD-Pipeline integriert

Priorität 3 -- Innerhalb eines Monats

• RBAC auf Namespace-Rollen (Role statt ClusterRole) umgestellt
• Egress-NetworkPolicies für ausgehenden Traffic konfiguriert
• Audit-Logging aktiviert und an SIEM angebunden
• Image Pull Policy auf Always und nur signierte Images erlaubt
• Pod Security Standards auf restricted hochgestuft

Audit automatisieren

Ein einmaliges Audit reicht nicht. Integrieren Sie Security-Checks in Ihren Workflow:

# kube-bench als CronJob (wöchentlich)
kubectl create cronjob kube-bench-weekly \
  --image=aquasec/kube-bench:latest \
  --schedule="0 6 * * 1" \
  -- kube-bench run --json

# kubescape für MITRE ATT&CK und NSA Hardening Checks
kubescape scan framework nsa --exclude-namespaces kube-system

Kombinieren Sie kube-bench (CIS Benchmark), Trivy (Image-Scanning) und kubescape (MITRE ATT&CK) für eine umfassende automatisierte Sicherheitsprüfung.

FAQ

Wie oft sollte ich ein Security Audit durchführen?

Automatisierte Scans (kube-bench, Trivy) sollten wöchentlich oder bei jedem Deployment laufen. Ein manuelles RBAC- und Policy-Review empfiehlt sich vierteljährlich. Nach größeren Cluster-Änderungen (Upgrades, neue Namespaces) führen Sie ein Ad-hoc-Audit durch.

Funktioniert kube-bench mit Managed Kubernetes?

Ja, aber mit Einschränkungen. Master-Node-Checks entfallen, da der Cloud-Provider die Control Plane verwaltet. Nutzen Sie --targets node,policies für Worker-Nodes und Policy-Checks. EKS, AKS und GKE haben eigene CIS-Benchmark-Profile in kube-bench.

Was ist der Unterschied zwischen Trivy und kubescape?

Trivy scannt Container-Images auf bekannte CVEs und Fehlkonfigurationen. kubescape prüft die Cluster-Konfiguration gegen Frameworks wie MITRE ATT&CK, NSA Hardening Guide und CIS Benchmark. Beide Tools ergänzen sich -- Trivy für Image-Sicherheit, kubescape für Cluster-Konfiguration.

Welche Findings haben die höchste Priorität?

Container mit privileged: true, ClusterRoleBindings zu cluster-admin für Anwendungen und fehlende etcd-Verschlüsselung. Diese drei Findings ermöglichen einem Angreifer die vollständige Übernahme des Clusters und sollten sofort behoben werden.