PodSecurityPolicy: Von der Idee zur Abschaffung – Ein Blick zurück

Die PodSecurityPolicy (PSP) wurde mit Kubernetes v1.25 entfernt. Diese Entscheidung wurde bereits zuvor in dem Blogbeitrag PodSecurityPolicy Deprecation: Past, Present, and Future angekündigt. In diesem Artikel werfen wir einen Blick auf die Entstehung und Entwicklung der PSP, erklären, warum sie nie stabil wurde und zeigen, weshalb sie durch die Pod Security Admission Control ersetzt wurde.

Die Entstehung der PodSecurityPolicy

Die PodSecurityPolicy hat ihre Wurzeln in den SecurityContextConstraints (SCC) von OpenShift, die bereits in der ersten Version der Red Hat OpenShift Container Platform implementiert waren, noch vor der Veröffentlichung von Kubernetes 1.0. Die PSP war eine vereinfachte Version der SCC.

Die genaue Entstehungsgeschichte der PodSecurityPolicy ist schwer nachzuvollziehen, da sie hauptsächlich vor dem Kubernetes Enhancements Proposal (KEP) Prozess hinzugefügt wurde, als Designvorschläge noch in einer anderen Form existierten. Das Archiv des endgültigen Designvorschlags ist jedoch noch verfügbar. Nachdem die ersten Pull-Requests gemerged wurden, wurde auch eine KEP-Nummer fünf erstellt.

Vor der Implementierung des ersten Codes, der die PSP erschuf, wurden zwei wichtige Pull-Requests in Kubernetes integriert: ein SecurityContext Subresource, das neue Felder für Container in Pods definierte, und die erste Iteration der ServiceAccount API.

Kubernetes 1.0 wurde am 10. Juli 2015 veröffentlicht, ohne Mechanismen zur Einschränkung des Sicherheitskontexts und sensibler Optionen für Workloads, abgesehen von einem alpha-Qualitäts SecurityContextDeny Admission Plugin (damals bekannt als scdeny). Der SecurityContextDeny Plugin ist auch heute noch in Kubernetes vorhanden (als Alpha-Feature) und erstellt einen Admission Controller, der die Nutzung bestimmter Felder im Sicherheitskontext verhindert.

Die Wurzeln der PodSecurityPolicy wurden mit dem ersten Pull-Request für Sicherheitsrichtlinien hinzugefügt, der den Designvorschlag mit dem neuen PSP-Objekt, basierend auf den SCC, enthielt. Es war eine lange Diskussion von neun Monaten, mit vielen Rückmeldungen aus OpenShift’s SCC, vielen Rebasen und der Umbenennung in PodSecurityPolicy, die schließlich im Februar 2016 in Kubernetes integriert wurde. Nachdem das PSP-Objekt erstellt war, war der nächste Schritt, einen Admission Controller hinzuzufügen, der diese Richtlinien durchsetzen konnte. Der erste Schritt war, den Admission hinzuzufügen, ohne die Benutzer oder Gruppen zu berücksichtigen. Ein spezifisches Issue, um die PodSecurityPolicy in einen nutzbaren Zustand zu bringen, wurde hinzugefügt, um den Fortschritt zu verfolgen, und eine erste Version des Admission Controllers wurde im Pull-Request namens PSP Admission im Mai 2016 gemerged. Etwa zwei Monate später wurde Kubernetes 1.3 veröffentlicht.

Der Weg zur Abschaffung der PodSecurityPolicy ist ein wichtiger Schritt, der zeigt, wie sich Sicherheitsrichtlinien in Kubernetes weiterentwickeln können. Für Entwickler und DevOps-Teams bedeutet dies, dass sie sich auf neue Sicherheitsmechanismen einstellen müssen, die die Verwaltung und Durchsetzung von Sicherheitsrichtlinien vereinfachen und verbessern werden. Bei ayedo unterstützen wir Sie gerne bei der Implementierung dieser neuen Sicherheitsstrategien!

Quelle: Kubernetes Blog