Kubernetes Security Audit: Was Unternehmen pruefen lassen sollten

TL;DR

• Ein systematisches Security Audit deckt Schwachstellen in RBAC, NetworkPolicies, Pod Security, Secrets Management und API-Server-Konfiguration auf
• Automatisierte Tools wie kube-bench, Kubescape und Trivy finden 60-70% der Probleme -- den Rest erfordert manuelles Review
• Die haeufigsten Findings sind zu breite RBAC-Rollen, fehlende NetworkPolicies und unverschluesselte Secrets
• Ein Audit sollte mindestens jaehrlich stattfinden, idealerweise halbjaehrlich oder nach groesseren Aenderungen am Cluster
• Priorisierung nach Severity und Exploit-Wahrscheinlichkeit ist entscheidend, um Ressourcen sinnvoll einzusetzen

Was ist ein Security Audit?

Ein Kubernetes Security Audit ist eine systematische Pruefung der Sicherheitskonfiguration eines Clusters. Dabei werden saemtliche sicherheitsrelevanten Komponenten analysiert: vom API-Server ueber RBAC-Regeln und NetworkPolicies bis hin zu Container-Images und Secrets Management.

Der Unterschied zu einem einfachen Vulnerability Scan: Ein Audit betrachtet nicht nur bekannte Schwachstellen in Software-Komponenten, sondern auch Fehlkonfigurationen, Architektur-Entscheidungen und operationale Prozesse. Ein Container-Image kann frei von CVEs sein und trotzdem als Root laufen, ohne Resource Limits und mit Zugriff auf das Host-Netzwerk.

Unternehmen, die Kubernetes in Produktion betreiben, sollten regelmaessig einen Kubernetes Security Audit durchfuehren lassen, um zu pruefen, ob ihre Cluster den aktuellen Best Practices entsprechen. Besonders relevant wird das bei Compliance-Anforderungen wie ISO 27001, BSI C5 oder branchenspezifischen Regulierungen.

Die acht Pruefbereiche eines Security Audits

1. RBAC-Review (Role-Based Access Control)

RBAC ist das zentrale Berechtigungssystem in Kubernetes. Fehlkonfigurationen hier sind besonders kritisch, weil sie laterale Bewegung im Cluster ermoeglichen.

Was geprueft wird:

• Welche Subjects (User, Groups, ServiceAccounts) haben cluster-admin-Rechte?
• Gibt es Rollen mit Wildcard-Verbs (*) oder Wildcard-Resources?
• Werden ServiceAccounts in Namespaces isoliert oder namespace-uebergreifend genutzt?
• Sind Default-ServiceAccounts deaktiviert oder eingeschraenkt?

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

# ServiceAccounts mit zu vielen Rechten finden
kubectl auth can-i --list --as=system:serviceaccount:default:default

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

Typisches Finding: Entwickler-Teams haben cluster-admin statt eingeschraenkter Namespace-Rollen. Das passiert oft in der Anfangsphase und wird nie zurueckgebaut.

2. NetworkPolicies

Ohne NetworkPolicies kann jeder Pod mit jedem anderen Pod kommunizieren -- ueber Namespace-Grenzen hinweg. Das ist das Kubernetes-Aequivalent eines flachen Netzwerks ohne Segmentierung.

Was geprueft wird:

• Gibt es Default-Deny-Policies in allen Namespaces?
• Sind Ingress- und Egress-Regeln definiert?
• Werden Namespaces als Isolationsgrenze genutzt?
• Ist das CNI-Plugin (Calico, Cilium, etc.) korrekt konfiguriert und unterstuetzt NetworkPolicies?

# Default-Deny fuer Ingress und Egress in einem Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

# 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: Namespace $ns hat keine NetworkPolicies"
  fi
done

3. Pod Security

Pod Security Standards (PSS) definieren drei Stufen: Privileged, Baseline und Restricted. Seit Kubernetes 1.25 ist Pod Security Admission (PSA) der offizielle Mechanismus zur Durchsetzung.

Was geprueft wird:

• Laufen Container als Root?
• Gibt es privilegierte Container oder Container mit erweiterten Capabilities?
• Sind hostNetwork, hostPID oder hostIPC aktiviert?
• Werden Security Contexts konsistent gesetzt?
• Ist Pod Security Admission auf Namespace-Ebene konfiguriert?

# Sicherer Security Context fuer einen Pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

# Pods finden, die als Root laufen
kubectl get pods -A -o json | \
  jq -r '.items[] |
  select(.spec.containers[].securityContext.runAsNonRoot != true) |
  "\(.metadata.namespace)/\(.metadata.name)"'

Detaillierte Informationen zu Pod Security Standards finden Sie in unserem Beitrag zu Kubernetes Pod Security Standards.

4. Image Scanning und Supply Chain Security

Container-Images sind die haeufigste Quelle fuer bekannte Schwachstellen. Ein Audit prueft nicht nur die Images selbst, sondern auch den gesamten Supply-Chain-Prozess.

Was geprueft wird:

• Werden Images vor dem Deployment auf CVEs gescannt?
• Gibt es eine Image-Policy (nur signierte Images, nur aus internen Registries)?
• Werden Base-Images regelmaessig aktualisiert?
• Sind Image-Tags fixiert (keine latest-Tags in Produktion)?
• Werden Distroless oder Minimal-Images verwendet?

# Trivy-Scan eines Images
trivy image --severity HIGH,CRITICAL nginx:1.25

# Images mit latest-Tag im Cluster finden
kubectl get pods -A -o json | \
  jq -r '.items[].spec.containers[] |
  select(.image | test(":latest$") or (test(":") | not)) |
  .image' | sort -u

5. Secrets Management

Kubernetes Secrets sind standardmaessig nur Base64-kodiert, nicht verschluesselt. Das ist eine der am haeufigsten uebersehenen Schwachstellen.

Was geprueft wird:

• Ist Encryption at Rest fuer etcd konfiguriert?
• Werden Secrets als Environment-Variablen oder als Volumes gemountet?
• Gibt es einen externen Secrets Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)?
• Werden Secrets in Git-Repositories committed?
• Sind Secrets auf bestimmte Namespaces und ServiceAccounts beschraenkt?

# EncryptionConfiguration fuer etcd
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: BASE64_ENCODED_32_BYTE_KEY
      - identity: {}

# Pruefen, ob Encryption at Rest aktiv ist
kubectl get pods -n kube-system -l component=kube-apiserver -o json | \
  jq -r '.items[].spec.containers[].command[]' | \
  grep encryption-provider-config

6. API-Server-Konfiguration

Der API-Server ist das Herzstueck jedes Kubernetes-Clusters. Was geprueft wird:

• Ist anonyme Authentifizierung deaktiviert?
• Werden Audit Logs geschrieben und ausgewertet?
• Sind Admission Controller korrekt konfiguriert (PodSecurity, ResourceQuota, LimitRange)?
• Ist der API-Server nur aus dem internen Netzwerk erreichbar?

# API-Server-Flags pruefen
kubectl get pods -n kube-system -l component=kube-apiserver -o json | \
  jq -r '.items[].spec.containers[].command[]' | sort

7. etcd-Sicherheit

etcd speichert den gesamten Cluster-State einschliesslich aller Secrets. Kompromittierter Zugriff auf etcd bedeutet vollstaendige Kontrolle ueber den Cluster.

Was geprueft wird:

• Ist die Kommunikation zwischen API-Server und etcd TLS-verschluesselt?
• Sind etcd-Zertifikate aktuell und korrekt konfiguriert?
• Ist etcd nur vom API-Server aus erreichbar?
• Werden etcd-Backups verschluesselt gespeichert?

# etcd-Endpoints und TLS-Konfiguration pruefen
kubectl get pods -n kube-system -l component=etcd -o json | \
  jq -r '.items[].spec.containers[].command[]' | grep -E "cert|key|ca"

8. Audit Logging

Kubernetes Audit Logs zeichnen auf, wer wann welche API-Aufrufe gemacht hat. Ohne Audit Logging ist Forensik nach einem Sicherheitsvorfall praktisch unmoeglich.

Was geprueft wird:

• Ist Audit Logging aktiviert?
• Welche Events werden geloggt (Audit Policy)?
• Werden Logs zentral gesammelt und aufbewahrt?
• Gibt es Alerting auf verdaechtige Aktivitaeten?
• Wie lange werden Audit Logs aufbewahrt?

# Beispiel Audit Policy
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Secrets-Zugriffe immer loggen
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
  # Authentifizierungsfehler loggen
  - level: Metadata
    nonResourceURLs:
      - "/api*"
    omitStages:
      - "RequestReceived"
  # Alles andere auf Metadata-Level
  - level: Metadata

Einen ausfuehrlichen Guide zum Thema finden Sie unter Kubernetes Audit Logging.

Audit-Methodik: Automatisiert und manuell

Ein professionelles Audit kombiniert automatisierte Scans mit manueller Analyse. Keines von beidem allein reicht aus.

Automatisierte Scans

Automatisierte Tools liefern schnelle Ergebnisse fuer bekannte Fehlkonfigurationen:

# kube-bench gegen CIS Benchmark ausfuehren
kube-bench run --targets master,node,etcd,policies

# Kubescape-Scan mit NSA-Framework
kubescape scan framework nsa --enable-host-scan

# Trivy Kubernetes-Cluster-Scan
trivy k8s --report summary cluster

Manuelle Analyse

Was automatisierte Tools nicht finden:

• Architektur-Schwaechen: Ist die Namespace-Struktur sinnvoll? Sind Umgebungen korrekt getrennt?
• Prozess-Luecken: Gibt es einen Onboarding/Offboarding-Prozess fuer Cluster-Zugriffe? Werden Berechtigungen regelmaessig reviewed?
• Business-Kontext: Welche Workloads sind besonders schuetzenswert? Welche Compliance-Anforderungen gelten?
• Konfigurationsdrift: Weichen Live-Konfigurationen von den Manifesten im Git-Repository ab?

Haeufige Findings und ihre Severity

Aus der Erfahrung zahlreicher Audits ergeben sich wiederkehrende Muster. Diese Tabelle zeigt die haeufigsten Findings, sortiert nach Schweregrad:

Findings priorisieren: Risiko-Matrix

Nicht jedes Finding muss sofort behoben werden. Eine sinnvolle Priorisierung beruecksichtigt zwei Faktoren: den potentiellen Schaden (Impact) und die Wahrscheinlichkeit der Ausnutzung (Likelihood).

Sofort beheben (P1):

• cluster-admin-Rechte fuer Nicht-Admins
• Privilegierte Container in Produktion
• Unverschluesselte etcd-Kommunikation
• Oeffentlich erreichbarer API-Server ohne Einschraenkungen

Innerhalb von 2 Wochen (P2):

• Fehlende NetworkPolicies
• Container die als Root laufen
• Fehlende Encryption at Rest
• Kein Audit Logging

Innerhalb von 4 Wochen (P3):

• latest-Tags in Produktion, fehlende Resource Limits, veraltete Base-Images

Backlog (P4):

• Image-Signierung, Service Mesh fuer mTLS, umfassende Policy-Engine-Ausrollung

Struktur eines Audit-Reports

Ein professioneller Audit-Report sollte diese Abschnitte enthalten:

1. Executive Summary: Gesamtbewertung, Top-3-Risiken, empfohlene Sofortmassnahmen. Maximal eine Seite, fuer Management lesbar.
2. Scope und Methodik: Welche Cluster, Tools und Frameworks kamen zum Einsatz? Was war ausgeschlossen?
3. Finding-Liste: Jedes Finding mit ID, Titel, Beschreibung, Severity, betroffene Ressourcen und Empfehlung.
4. Risiko-Bewertung: Zusammenfassende Bewertung nach Kategorien mit Score oder Ampel-System.
5. Massnahmenplan: Priorisierte Liste mit geschaetztem Aufwand und Verantwortlichkeiten.
6. Anhang: Rohdaten der Scans, Konfigurationsauszuege, Screenshots.

Wie oft sollte ein Audit stattfinden?

Die optimale Frequenz haengt von mehreren Faktoren ab:

Zusaetzlich zu periodischen Audits sollten automatisierte Compliance-Checks kontinuierlich laufen. Tools wie Kubescape oder Kyverno koennen als Teil der CI/CD-Pipeline bei jedem Deployment pruefen. Mehr dazu in unserem Artikel zur Kubernetes Compliance Automatisierung.

Internes vs. externes Audit

Beide Varianten haben ihre Berechtigung:

Internes Audit: Schneller, guenstiger, Team kennt den Kontext. Risiko: Betriebsblindheit und fehlende Benchmark-Erfahrung.

Externes Audit: Unabhaengige Perspektive, Erfahrung aus vielen Clustern, erforderlich fuer Compliance-Nachweise (ISO 27001, BSI C5). Hoehere Kosten, aber systematischere Abdeckung.

Die ideale Kombination: Interne Teams fuehren quartalsweise automatisierte Scans durch und beheben Findings selbststaendig. Ein externer Audit findet jaehrlich statt und liefert die unabhaengige Bewertung fuer Compliance-Zwecke.

Checkliste: Vorbereitung auf ein Security Audit

Bevor ein externes Audit startet, sollten Sie diese Punkte vorbereiten:

• Read-Only-ServiceAccount fuer die Auditoren erstellen
• Dokumentation der Cluster-Architektur bereithalten
• Zugang zu Monitoring und Logging sicherstellen
• Liste der eingesetzten Third-Party-Operatoren und Helm Charts
• Vorhandene Security-Policies und Compliance-Anforderungen dokumentieren
• Ergebnisse frueherer Audits (falls vorhanden) bereitstellen

Fazit

Ein Security Audit ist keine einmalige Pflichtaufgabe, sondern ein wiederkehrender Prozess, der die Sicherheitslage Ihres Clusters kontinuierlich verbessert. Die Kombination aus automatisierten Tools und manueller Expertise deckt systematisch Schwachstellen auf, die im Tagesgeschaeft untergehen.

Starten Sie mit den automatisierten Tools: Installieren Sie kube-bench und Kubescape, fuehren Sie die ersten Scans durch und arbeiten Sie die kritischen Findings ab. Fuer eine umfassende Bewertung und Compliance-Nachweise empfiehlt sich ein professionelles externes Audit.

Verwandte Artikel

• Kubernetes Compliance automatisieren: Gatekeeper, Kyverno und Trivy
• Kubernetes Pod Security Standards
• Kubernetes Audit Logging
• Kubernetes Secrets Management mit Vault
• Kubernetes Network Security

Sie moechten einen professionellen Security Audit fuer Ihre Kubernetes-Cluster durchfuehren lassen? Wir pruefen Ihre Infrastruktur systematisch und liefern einen priorisierten Massnahmenplan. Kontaktieren Sie uns unter /kontakt.