Kubernetes Pod Security Standards: Cluster absichern ohne Overhead

Mit Kubernetes 1.25 wurden PodSecurityPolicies endgültig entfernt. Ihr Nachfolger — die Pod Security Standards — ist seit 1.23 stabil und in jedem aktuellen Cluster verfügbar. Trotzdem laufen in der Praxis noch viele Produktions-Workloads ohne aktive Enforcement-Policy. Das ist kein theoretisches Risiko: Ein kompromittierter Container mit privileged: true kann den Host übernehmen.

Dieser Artikel erklärt, wie Pod Security Standards funktionieren, welche Stufe für welchen Workload sinnvoll ist, und wie man mit kubeaudit den aktuellen Sicherheitsstatus eines Clusters schnell bewertet.

Was sind Pod Security Standards?

Pod Security Standards (PSS) sind drei vordefinierte Profile, die Kubernetes nativ mitbringt. Sie werden über den Pod Security Admission Controller erzwungen — einem Webhook, der seit 1.23 standardmäßig aktiv ist.

• Privileged: Keine Einschränkungen. Geeignet für System-Namespaces wie kube-system, niemals für Applikations-Workloads.
• Baseline: Verhindert bekannte Privilege-Escalation-Angriffe (z. B. hostPID, hostNetwork, privileged Containers). Gut geeignet als Einstieg für die meisten Produktions-Namespaces.
• Restricted: Strenge Härtung nach aktuellem Stand der Technik. Erfordert non-root-User, dropped Capabilities, read-only Filesystem. Für neue Services direkt empfehlenswert.

Jedes Profil kann in drei Modi betrieben werden: enforce (Pod wird abgelehnt), audit (Verstoß wird geloggt, Pod läuft) und warn (Benutzer sieht eine Warnung bei kubectl). Für die Migration empfiehlt sich der Weg: zuerst warn, dann audit, schließlich enforce.

Namespace-Label in der Praxis

PSS wird per Namespace-Label konfiguriert. Ein konkretes Beispiel für einen Produktions-Namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest

Dieser Namespace erzwingt Baseline, loggt und warnt aber bereits bei Verstößen gegen Restricted. So sieht man, welche Workloads noch angepasst werden müssen, ohne den Betrieb sofort zu unterbrechen.

kubeaudit: Sicherheitsstatus in Minuten sichtbar machen

kubeaudit ist ein Open-Source-CLI-Tool (Shopify), das einen laufenden Cluster oder lokale Manifeste gegen bekannte Security-Probleme prüft. Es deckt unter anderem ab:

• Fehlende oder falsche Security Contexts
• Capabilities, die nicht gedropped wurden
• Container, die als root laufen
• Fehlende Network Policies
• Image-Tags ohne Digest (Mutable Tags)
• Secrets als Umgebungsvariablen statt als gemountete Volumes

Einfacher Einstieg gegen einen Live-Cluster:

# Alle Namespaces prüfen
kubeaudit all

# Nur einen Namespace
kubeaudit all -n production

# Gegen lokale Manifeste
kubeaudit all -f deployment.yaml

Die Ausgabe klassifiziert Befunde in ERROR, WARNING und INFO. Jeder Befund enthält einen Audit-Code (z. B. AppArmorAnnotationMissing) und eine Handlungsempfehlung.

PSS und kubeaudit: Zusammenspiel verstehen

PSS und kubeaudit ergänzen sich, ersetzen sich aber nicht gegenseitig. PSS greift zur Laufzeit auf API-Server-Ebene — es verhindert, dass nicht-konforme Pods überhaupt gestartet werden. kubeaudit analysiert statisch und deckt Probleme auf, die PSS nicht abdeckt (z. B. fehlende Network Policies, AppArmor-Annotierungen, Image-Digest-Pinning).

Wer zusätzlich dynamische Admission-Kontrolle mit eigenen Regeln benötigt, kombiniert PSS mit einem Policy-Engine wie Kyverno. Der Unterschied: PSS ist standardisiert und wartungsarm, Kyverno ist flexibler, erfordert aber eigene Policy-Pflege.

Häufige Fehler bei der Einführung

In der Praxis sehen wir wiederholt dieselben Muster, wenn Teams PSS einführen:

• kube-system direkt auf Restricted setzen: Viele System-Komponenten (z. B. CNI-Plugins, node-local-dns) benötigen privilegierte Rechte. kube-system bleibt auf Privileged, eigene Namespaces bekommen strikte Policies.
• enforce ohne vorherige audit-Phase: Führt zu sofortigen Deployment-Fehlern in Produktion, die schwer zu debuggen sind.
• Helm Charts nicht prüfen: Third-party Charts setzen oft Standard-Security-Contexts, die mit Restricted kollidieren. Immer mit --dry-run testen.
• PSS als alleinige Sicherheitsmaßnahme: PSS schützt auf Pod-Ebene. Network Policies, RBAC, Image-Scanning und Secret-Management sind separate, notwendige Schichten.

Defense in Depth: PSS als eine Schicht von mehreren

Ein gehärteter Kubernetes-Cluster folgt dem Prinzip Defense in Depth. PSS ist die Admissions-Schicht. Darunter liegen:

• RBAC: Wer darf was im Cluster? Least-Privilege für alle Service-Accounts.
• Network Policies: Default-deny per Namespace, explizite Freigaben pro Service.
• Image-Scanning: CVE-Checks im Build und zur Laufzeit (Trivy, Grype).
• Secret-Management: Kein Base64 in etcd — stattdessen External Secrets Operator mit Vault oder AWS Secrets Manager.
• Audit-Logging: Wer hat wann welche Ressource verändert? Mandatory für BSI-Grundschutz-konforme Umgebungen.

PSS ohne Network Policies ist wie eine verschlossene Tür ohne Zaun. Beide Ebenen müssen aktiv sein.

Wann lohnt sich ein externer Sicherheits-Review?

Ein manueller Durchlauf mit kubeaudit dauert 30 Minuten. Ein vollständiges Security-Review eines Produktions-Clusters — inklusive RBAC-Analyse, Network-Policy-Kartierung, Secret-Management-Bewertung und Vergleich mit BSI-Empfehlungen — dauert mehrere Tage und erfordert Erfahrung mit den typischen Schwachstellen produktiver Cluster.

Für Teams, die ihren Cluster das erste Mal strukturiert auf Sicherheit prüfen wollen oder vor einem Compliance-Audit stehen (ISO 27001, SOC 2, BSI IT-Grundschutz), ist ein externer Kubernetes-Security-Audit sinnvoll — nicht als Ersatz für internes Wissen, sondern als unabhängige Perspektive.

Mehr erfahren: Kubernetes-Beratung oder Audit buchen.