PodSecurity restricted: der Namespace, in dem keine Pods starten

Ein guter Kubernetes-Cluster ist gehärtet, und eine der wirksamsten Härtungen ist der PodSecurity-Standard restricted als Default. Er lässt nur Pods zu, die mit minimalen Rechten laufen. Das ist richtig so, aber die erste Begegnung damit kostet Nerven, weil der Fehler leise ist.

Was passiert

Ich lege in einem Namespace mit dem Label enforce=restricted ein ganz normales Deployment an. Das Deployment wird angelegt, meldet keinen Fehler, und trotzdem startet kein einziger Pod:

Der entscheidende Punkt: Der Fehler steht nicht am Deployment und nicht am Pod (es gibt ja keinen), sondern als FailedCreate-Event am ReplicaSet dazwischen. Wer nur auf den obersten Status schaut

kubectl get deploy

sieht „0/1“ und keinen Grund. Man muss die Events lesen. Welches Profil ein Namespace erzwingt, steuert das Label der Pod Security Admission.

Warum es scheitert

restricted verlangt von jedem Container vier Dinge: nicht als root laufen (runAsNonRoot), keine Rechteausweitung (allowPrivilegeEscalation: false), alle Linux-Capabilities ablegen (drop: ["ALL"]) und ein seccomp-Profil (RuntimeDefault). Ein Standard-Image wie nginx bringt davon nichts mit, also wird sein Pod abgewiesen.

Die Lösung: securityContext am Workload

Der richtige Weg ist nicht, die Härtung aufzuweichen, sondern dem Workload den passenden securityContext mitzugeben:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  seccompProfile:
    type: RuntimeDefault
  capabilities:
    drop: ["ALL"]

Ein Sonderfall sind Infrastruktur-Namespaces, die bewusst mehr dürfen müssen (manche Datenbank- oder Netzwerk-Komponenten). Die labelt man gezielt auf baseline oder privileged, statt den Default für alle zu senken. Und Vorsicht bei GitOps: neue Namespaces, die ArgoCD anlegt, tragen zunächst kein PodSecurity-Label und fallen damit auf den restriktiven Cluster-Default, ein häufiger Grund, warum eine frisch ausgerollte App scheinbar grundlos leer bleibt.

Ehrlich: Härtung verschiebt Arbeit in die Workloads

restricted als Default ist die richtige Entscheidung, aber sie ist nicht gratis. Jeder Workload muss seinen securityContext mitliefern, und viele fertige Charts tun das nicht von sich aus. Der stille FailedCreate ist am Ende eine gute Lehre: In Kubernetes liest man Events, nicht nur den obersten Status.

Sie wollen einen Cluster, der sicher ist und trotzdem zuverlässig ausrollt? Ich härte Kubernetes-Umgebungen so, dass die Absicherung greift, ohne dass Deployments still liegen bleiben. Mehr unter IT-Sicherheit & ISMS, das Erstgespräch ist unverbindlich.