Kubernetes Pod Security Standards: Cluster absichern ohne PodSecurityPolicy

Seit Kubernetes 1.25 ist PodSecurityPolicy (PSP) endgültig entfernt. Wer seinen Cluster noch mit PSP abgesichert hat — oder wer die Migration bisher aufgeschoben hat — steht vor einer konkreten Sicherheitslücke. Der offizielle Nachfolger heißt Pod Security Standards (PSS), durchgesetzt über den integrierten Pod Security Admission-Controller. Dieser Artikel erklärt, wie PSS funktioniert, wo die Grenzen liegen und was Mittelstandsunternehmen bei der Umsetzung beachten müssen.

Was sind Pod Security Standards?

Pod Security Standards definieren drei vordefinierte Sicherheitsprofile für Pods:

• Privileged: Keine Einschränkungen. Geeignet ausschließlich für System-Namespaces wie kube-system.
• Baseline: Verhindert bekannte Privilege-Escalation-Vektoren. Sinnvoller Ausgangspunkt für produktive Workloads.
• Restricted: Folgt den aktuellen Best Practices für Pod-Härtung. Erfordert explizit konfigurierte Security Contexts in jedem Workload.

Die Standards werden per Namespace-Label aktiviert. Kubernetes prüft dann jeden neuen Pod gegen das definierte Profil — ohne externe Webhook-Infrastruktur.

Enforcement-Modi: warn, audit, enforce

PSS kennt drei unabhängige Modi pro Namespace, die parallel aktiv sein können:

• enforce: Pods, die gegen das Profil verstoßen, werden abgelehnt.
• audit: Verstöße werden im Audit-Log festgehalten, der Pod wird dennoch zugelassen.
• warn: Der API-Server gibt eine Warnung zurück — sichtbar in kubectl-Ausgaben und CI/CD-Logs.

Ein typisches Migrations-Vorgehen: Zunächst nur warn und audit aktivieren, alle Verstöße beheben, dann auf enforce wechseln. Dadurch vermeidet man unerwartete Produktionsausfälle.

Namespace-Labels korrekt setzen

Die Konfiguration erfolgt ausschließlich über Labels am Namespace-Objekt. Ein Beispiel für einen produktiven Application-Namespace:

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

Das -version-Label ist wichtig: Es friert den Standard auf eine bestimmte Kubernetes-Version ein. Beim Cluster-Upgrade ändert sich das Verhalten dann nicht automatisch — Sie entscheiden bewusst, wann Sie auf eine neuere Profil-Version wechseln.

Was PSS nicht abdeckt — und wann Sie mehr brauchen

Pod Security Standards sind ein solider Basisschutz, aber kein vollständiges Security-Framework. Folgende Anforderungen lassen sich damit nicht abbilden:

• Feingranulare Policies: PSS ist binär — entweder das Profil passt oder nicht. Individuelle Ausnahmen für einzelne Workloads innerhalb eines Namespace sind nicht möglich.
• Image-Policies: PSS prüft nicht, ob ein Container-Image aus einer vertrauenswürdigen Registry stammt oder signiert ist.
• Mutation: PSS kann keine Felder automatisch ergänzen (z. B. securityContext setzen). Dafür brauchen Sie einen Mutating Webhook — oder Kyverno mit einer entsprechenden Policy.
• Runtime-Sicherheit: PSS greift zur Admission-Zeit. Was ein Container zur Laufzeit tut, überwacht PSS nicht. Dafür ist Falco oder ein vergleichbares Runtime-Security-Tool zuständig.

Für Umgebungen mit DSGVO-Anforderungen oder branchenspezifischen Compliance-Vorgaben (BSI IT-Grundschutz, ISO 27001) reicht PSS allein in der Regel nicht aus. Ein durchdachtes Sicherheitskonzept kombiniert PSS mit RBAC, Network Policies, Secret Management und Audit-Logging.

PSS und Kyverno: sinnvolle Ergänzung

Kyverno ist ein Kubernetes-nativer Policy-Controller, der deutlich flexibler ist als PSS. Beide schließen sich nicht aus — im Gegenteil: PSS als Basislinie im Admission-Controller, Kyverno für spezifische Unternehmensrichtlinien (z. B. Pflicht-Labels, erlaubte Registries, Resource-Limits) ist ein bewährtes Muster. Kyverno kann außerdem Exceptions zu PSS-Profilen granular abbilden, ohne den gesamten Namespace auf ein niedrigeres Profil herabzustufen.

Migration von PodSecurityPolicy: Schritt für Schritt

Falls Sie noch auf einem Kubernetes-Cluster unter Version 1.25 arbeiten oder gerade migrieren:

1. Bestehende PSPs inventarisieren und dem jeweiligen PSS-Profil zuordnen (Privileged, Baseline oder Restricted).
2. PSS im warn- und audit-Modus für alle Namespaces aktivieren.
3. Audit-Logs und kubectl-Warnungen auswerten — alle Workloads mit Verstößen identifizieren.
4. Security Contexts in Deployments, StatefulSets und DaemonSets korrigieren: runAsNonRoot: true, allowPrivilegeEscalation: false, seccompProfile setzen.
5. enforce-Modus namespace-weise aktivieren, beginnend mit weniger kritischen Namespaces.
6. PSP-Objekte und den PodSecurityPolicy-Admission-Plugin-Eintrag entfernen.

Fazit

Pod Security Standards sind der richtige erste Schritt für jeden Kubernetes-Cluster, der produktive Workloads betreibt. Sie sind einfach zu konfigurieren, benötigen keine externe Infrastruktur und decken die häufigsten Angriffsvektoren auf Pod-Ebene ab. Ihre Grenzen bei feingranularen Policies und Runtime-Sicherheit sind bekannt — wer diese abdecken will, kombiniert PSS mit Kyverno und einem Observability-Stack.

Wenn Sie unsicher sind, ob Ihr Cluster-Security-Setup den aktuellen Standards entspricht, oder wenn Sie die Migration von PSP noch vor sich haben: Ein strukturierter Blick von außen hilft oft mehr als Wochen interner Diskussion.

Mehr erfahren: Kubernetes-Beratung oder Audit buchen.