Warum Kubernetes PodSecurityPolicy entfernt hat und was es ersetzt

In einem Beitrag im Kubernetes Blog im August 2022 stellte das Projekt den historischen Kontext für die Entfernung von PodSecurityPolicy (PSP) bereit. Dieser Admission-Controller wurde in Kubernetes v1.25 offiziell entfernt, nachdem ein langer Deprecation-Zyklus mit der Version v1.21 begonnen hatte. Der Artikel erklärt, warum PSP den Status „stabil“ nie erreichte und wie sein Nachfolger, Pod Security Admission, diese Mängel behebt.

Was passiert ist

PodSecurityPolicy entstand aus den SecurityContextConstraints (SCC) von OpenShift, die bereits in der ersten Version der Red Hat OpenShift Container Platform vor Kubernetes 1.0 existierten. PSP war im Wesentlichen eine abgespeckte Version von SCC, konzipiert für Upstream-Kubernetes. Die Erstellung erfolgte vor dem formalisierten Kubernetes Enhancements Proposal (KEP)-Prozess, was die frühe Designgeschichte schwer nachvollziehbar macht. Archive zeigen jedoch, dass der finale Designvorschlag erst erstellt wurde, nachdem die ersten Code-Merges bereits stattgefunden hatten.

Die Wurzeln von PSP wurden durch eine Reihe von Pull Requests ab 2015 gelegt. Bevor PSP existierte, fehlten in Kubernetes 1.0, veröffentlicht am 10. Juli 2015, Mechanismen zur Einschränkung von Sicherheitskontexten über ein Alpha-Qualitäts-Plugin namens SecurityContextDeny hinaus. Das erste PSP-Objekt, basierend auf den SCC von OpenShift, wurde im Februar 2016 nach neunmonatiger Diskussion in Upstream-Kubernetes integriert. Der Admission-Controller folgte im Mai 2016, wobei später im Jahr Autorisierungsmechanismen hinzugefügt wurden, um unterschiedliche Richtlinien für verschiedene Benutzer zu ermöglichen.

Trotz guter Absichten erreichte PSP nie den stabilen Status. Es litt unter einem fehlerhaften Autorisierungsmodell, Schwierigkeiten bei der Bereitstellung und einer inkonsistenten API. Daher beschloss die Kubernetes-Community, es vollständig in v1.25 zu entfernen. Es wurde durch Pod Security Admission ersetzt, ein neues In-Tree-Plugin, das Pod Security Standards auf Namespace-Ebene durchsetzt.

Wie es funktioniert

PodSecurityPolicy fungierte als spezialisiertes Admission-Control-Plugin, das granulare Berechtigungen für Pod-Sicherheitsfelder bot. Ziel war es, niedrigstufige Linux-Sicherheitsentscheidungen vom Bereitstellungsprozess zu entkoppeln, damit Clusteradministratoren sichere Standardeinstellungen festlegen konnten, ohne dass jeder Nutzer komplexe Sicherheitsprimitiven verstehen musste. Das System stützte sich auf Mutation und Validierung, um Regeln wie das Ausführen als Nicht-Root-Nutzer oder die Einschränkung der Rechteausweitung durchzusetzen.

Allerdings operierte PSP auf einer Fail-Closed-Basis. Wenn keine Richtlinie vorhanden war, wurden alle Pods abgelehnt. Dies erschwerte die standardmäßige Aktivierung, da Administratoren Richtlinien für jede Workload erstellen mussten, bevor sie die Funktion aktivieren konnten. Es gab keinen Audit-Modus, um zu identifizieren, welche Pods unter neuen Richtlinien scheitern würden, was zu häufigen Fehlern und unzureichender Testabdeckung führte. Darüber hinaus wuchs die API im Laufe der Zeit inkonsistent, um Nischenanwendungsfälle zu accommodieren, was die Kombination mit anderen Admission-Controllern erschwerte.

Der Ersatz, Pod Security Admission, vereinfacht dieses Modell, indem er drei vordefinierte Pod Security Standards durchsetzt: Privileged, Baseline und Restricted. Privileged ist uneingeschränkt, Baseline erlaubt Standardkonfigurationen und Restricted setzt Sicherheitsbest Practices durch. Dieser Ansatz beseitigt die Notwendigkeit tiefgreifender Sicherheitskenntnisse für die meisten Nutzer und bietet einen stabilen Durchsetzungsmechanismus auf Namespace-Ebene, der leichter zu adoptieren und zu warten ist.

Wichtige Details

• PodSecurityPolicy wurde in Kubernetes v1.25 entfernt, nachdem es in v1.21 als veraltet markiert wurde.
• PSP entstand aus den SecurityContextConstraints von OpenShift und wurde im Februar 2016 in Kubernetes integriert.
• Die Funktion erreichte aufgrund eines fehlerhaften Autorisierungsmodells und der Komplexität der Bereitstellung nie den stabilen Status.
• PSP operierte auf einer Fail-Closed-Basis und erforderte Richtlinien für alle Workloads vor der Aktivierung.
• Pod Security Admission ersetzt PSP durch drei Standards: Privileged, Baseline und Restricted.
• Der neue Admission-Controller ist in Kubernetes v1.25 stabil und arbeitet auf Namespace-Ebene.

Warum es wichtig ist

Für Software-Ingenieure und Plattformteams ist das Verständnis des Wandels von PSP zu Pod Security Admission entscheidend für die Aufrechterhaltung sicherer Cluster. PSP erforderte erhebliches Fachwissen in Linux-Sicherheitsprimitiven und sorgfältiges Management von Richtlinien, um Fehler bei der Bereitstellung zu vermeiden. Die Entfernung signalisiert eine Hinwendung zu einfacheren, stärker meinungsbasierten Sicherheitsstandardeinstellungen, die leichter umzusetzen sind und weniger anfällig für Konfigurationsfehler sind.

Die neuen Pod Security Standards bieten einen klaren Weg zur Absicherung von Workloads ohne den Overhead des Managements komplexer, benutzerdefinierter Richtlinien. Durch den Fokus auf drei unterschiedliche Restriktionsstufen macht Kubernetes es Entwicklern leichter, Sicherheitsbest Practices zu übernehmen, ohne tiefgehende Kenntnisse der zugrunde liegenden Sicherheitsmechanismen zu benötigen. Diese Änderung reduziert das Risiko von Fehlkonfigurationen und verbessert die allgemeine Sicherheitslage von Kubernetes-Clustern.

Was Sie tun können

• Aktualisieren Sie Ihre Cluster auf Kubernetes v1.25 oder neuer, um den stabilen Pod Security Admission Controller zu nutzen.
• Überprüfen Sie Ihre bestehenden Workloads, um sicherzustellen, dass sie den Baseline- oder Restricted-Pod-Security-Standards entsprechen.
• Ersetzen Sie alle verbleibenden PodSecurityPolicy-Objekte durch Labels auf Namespace-Ebene, die den gewünschten Sicherheitsstandard durchsetzen.
• Nutzen Sie den in früheren Versionen verfügbaren Audit-Modus, um Pods zu identifizieren, die unter den neuen Standards scheitern würden, bevor Sie diese durchsetzen.
• Konsultieren Sie die Kubernetes-Dokumentation für praktische Tutorials zur Implementierung von Pod Security Admission.
• Für anspruchsvolle Anwendungsfälle, die nicht von den integrierten Standards abgedeckt werden, bewerten Sie Drittanbieter-Admission-Controller, die Pod Security Admission ergänzen können.