Bereits über fünf Jahre ist es her, dass Pod Security Policies (PSP) in Kubernetes durch die neueren Pod Security Standards (PSS) abgelöst wurden. Einer der wichtigsten Gründe für diese tiefgreifende Änderung war eine einfachere Handhabe – und trotzdem kommen Pod Security Standards auch heute längst nicht in allen Clustern zum Einsatz.
In unserem heutigen Blogpost geht es deswegen um die Funktion, Hintergründe und Vorteile von Pod Security Standards und der Pod Security Admission (PSA), die du in jedem standardkonformen Kubernetes Cluster ohne großen Aufwand aktivieren und konfigurieren kannst.
Was sind Pod Security Standards
Pod Security Standards in Kubernetes legen – der Name verrät es bereits – gewisse sicherheitsrelevante Kriterien für die Konfiguration von Pods fest. Diese können in verschiedenen Modi clusterweit oder auf Namespace-Ebene durch Konfiguration des Pod Security Admission Controllers angewendet werden.
Warum der Umstieg von PSP auf PSS?
Die ursprüngliche Ankündigung des Features inklusive Abkündigung von Pod Security Policies nennt vor Allem zwei Punkte für die Umstellung und Notwendigkeit solcher Standards:
- Verwirrung bei der Anwendung: Die Konfiguration von PSPs für Pods stiftete oft Verwirrung und resultierte in weiteren Befugnissen als eigentlich gedacht.
- Fehlendes Sicherheitsnetz: Für PSPs gab es keinen „Dry Run“ oder Auditmodus; außerdem waren nur bestimmte Teile der Podkonfiguration unterstützt. Cluster nachträglich auf PSPs umzustellen war aufwändig und voller Fallstricke.
Eine Weiterentwicklung des PSP Admission Controllers war aus diesen und anderen Gründen nicht sinnvoll – die Entwicklung eines neuen Standards basierend auf den Erfahrungen (positiven wie negativen) jedoch schon. Das Resultat ist die Ausarbeitung der Pod Security Standards mit seinen Sicherheitsprofilen und neuem Admission Controller in KEP 2579.
Verfügbare PSS Profile
Um die Ausgangslage nicht zu verkomplizieren – für komplexere Anwendungsfälle gibt es schließlich Lösungen wie OPA Gatekeeper oder Kyverno – sind lediglich drei sogenannte Profile definiert, mit denen du arbeiten kannst:
privileged: Eigentlich das Gegenteil eines Sicherheitsstandards, denn dieses Profil definiert sich durch die Abwesenheit jeglicher Regeln. Pods können nach Belieben konfiguriert werden, und bekannte Exploits (z.B. Privilege Escalations) funktionieren in diesem Profil.baseline: Ein vernünftiges Standardprofil für die meisten Anwendungs- und Podkonfigurationen. Es unterbindet die Konfiguration von Einstellungen, die bekannte Exploits ermöglichen würden; Pods in ihrer Minimalkonfiguration werden allerdings akzeptiert und sind betreibbar.restricted: Das strikteste Pod Security Standards Profil verbietet deutlich mehr Konfigurationen als dasbaselineProfil und setzt eine möglichst sichere Konfiguration von Pods voraus. So können Container in Pods bspw. nicht alsrootbetrieben werden.
Die detaillierte Auflistung aller angelegten Kriterien pro Pod Security Standards Profil findest du in der offiziellen Dokumentation.
Diese Profile müssen nun auf die Pods in deinem Cluster angewendet werden – hier kommt der Pod Security Admission Controller ins Spiel.
Der Pod Security Admission Controller
Anfragen an Kubernetes über seine API durchlaufen vor der Umsetzung durch die verschiedenen Kubernetes-Komponenten eine strikte Folge von Schritten:
- Authentifizierung (Wer stellt die Anfrage?)
- Autorisierung (Darf die authentifizierte Entität diese Anfrage stellen?)
- Admission Control, aufgeteilt in drei Schritte:
- Mutating Admission Controller, die in der Anfrage enthaltene Objekte bei Bedarf anpassen können (z.B. um Sidecars zu injizieren oder Standardwerte zu setzen)
- Objektschemavalidierung, um die (möglicherweise veränderten) in der Anfrage enthaltenen Objekte gegen Kubernetes‘ OpenAPI-Schema zu validieren
- Validating Admission Controller, um die (möglicherweise veränderten) in der Anfrage enthaltenen Objekte endgültig zu akzeptieren oder abzulehnen
- Persistenz in etcd (in der Anfrage enthaltene Objekte werden dauerhaft gespeichert)
- Antwort an den Client (Was war das Ergebnis der Schritte 1-4?)
Da Pod Security Standards eine klare Ja/Nein Entscheidung auf Basis der angelegten Kriterien erfordern, und zu unsichere Pods gar nicht erst ausgeführt werden sollen, sitzt der Pod Security Admission Controller in Schritt 3.3 dieser Abfolge. Hierbei kontrolliert der Admission Controller alle Anfragen, die entweder Pods direkt oder einen Controller, der Pods verwaltet, betreffen würden, auf die Einhaltung des definierten Pod Security Standards Profils, unter Anderem:
- Pods
- Deployments
- StatefulSets
- Jobs
Wissenswert ist an dieser Stelle, dass bei Nichteinhaltung des definierten Standards lediglich die Erstellung des Pods fehlschlägt – ein Deployment würde bspw. problemlos erstellt werden – die von diesem definierten und verwalteten Pods allerdings nicht.
Konfiguration des Pod Security Admission Controllers
Da der Pod Security Admission Controller genau wie die Pod Security Standards Teil von Kubernetes selbst sind, ist eine Konfiguration des Admission Controllers ohne Installation zusätzlicher Anwendungen möglich. Hierzu benötigt man einen entsprechenden Eintrag in einer YAML-Datei, die das Verhalten der konfigurierten Admission Controller definiert, bspw. admission-configuration.yaml:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
# Defaults applied when a mode label is not set.
#
# Level label values must be one of:
# - "privileged" (default)
# - "baseline"
# - "restricted"
#
# Version label values must be one of:
# - "latest" (default)
# - specific version like "v1.36"
defaults:
enforce: "privileged"
enforce-version: "latest"
audit: "privileged"
audit-version: "latest"
warn: "privileged"
warn-version: "latest"
exemptions:
# Array of authenticated usernames to exempt.
usernames: []
# Array of runtime class names to exempt.
runtimeClasses: []
# Array of namespaces to exempt.
namespaces: []Diese Datei muss dann dem Kubernetes API-Server als Dateipfad unter dem Argument --admission-control-config-file mitgegeben werden.
Das obige Beispiel aus der Kubernetes Dokumentation legt hierbei für alle Namespaces im Cluster das Pod Security Standards Profil privileged fest, sodass jegliche Podkonfiguration akzeptiert wird. Doch was bedeuten die Keys enforce, audit und warn?
Die Modi des Pod Security Admission Controllers
Eines der formulierten Ziele während der Ausarbeitung von Pod Security Standards war die Fähigkeit, das Feature als Clusterbetreiber einfach einschalten zu können, ohne Nutzer in ihren Prozessen zu stören. Aus diesem Grund gibt es drei Modi, die unabhägig voneinander konfiguriert werden können:
warngibt bei Nichtbestehen der Überprüfung durch den Admission Controller eine Warnung an den Nutzer zurück, akzeptiert aber die betroffene Podkonfiguration.auditerstellt eine Audit-Annotation am beobachteten Event (bspw. die Erstellung eines Pods) im Audit Log des API-Servers (sofern Audit Logging aktiviert is), akzeptiert aber die betroffene Podkonfiguration.enforcelehnt sämtliche Podkonfigurationen ab, die nicht dem definierten Pod Security Standards Profil entsprechen.
Die Modi können hierbei frei kombiniert werden, über Profile und Modi hinweg. Das obige Beispiel definiert für alle drei Modi des Admission Controllers das Profil privileged, was gleichbedeutend mit absoluter Funkstille ist – jeder Pod wird vom Admission Controller akzeptiert, es gibt also auch nie Warnungen oder auditierbare Annotationen.
Konfiguration auf Namespace-Ebene
Spannender als obiges Beispiel ist die Möglichkeit, PSS-Profile und Admission Controller Modi auf Namespace-Ebene zu definieren. Mit obigem Beispiel läuft der Admission Controller, winkt aber jegliche Konfiguration durch – auch unsichere. Möchtest du nun bspw. den Namespace default weiter absichern, kannst du das mit einer Kombination von Labels am Namespace-Objekt tun:
apiVersion: v1
kind: Namespace
metadata:
name: default
labels:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/enforce-version: v1.35
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: latestMit dieser Konfiguration über Labels verhalten sich Pods im Namespace default nun so:
- Pods, die dem PSS Profil
baselineinv1.35entsprechen, werden vom Admission Controller akzeptiert und anschließend geschedult. - Genügt ein Pod dem PSS Profil
restrictedin seiner neuesten Fassung nicht, wird eine Annotation am Audit-Log-Event erstellt, und der Nutzer erhält eine aussagekräftige Warnung, welche Einstellungen nicht konform sind.
Mit einer solchen Konfiguration kannst du als Cluster-Administrator deine Nutzer vorsichtig auf anstehende Änderungen vorbereiten: Existierende Podkonfigurationen, die in Kubernetes v1.35 dem baseline Profil entsprachen, werden auch weiterhin erstellt (z.B. nach einem Upgrade von Kubernetes auf v1.36). Zusätzlich kriegen Nutzer direktes Feedback vom Admission Controller, wo sie noch nachbessern müssen, um den strikteren Anforderungen des restricted Profils zu genügen, und dank der Audit-Annotationen kannst auch du als Administrator solche Verstöße im Auge behalten.
Pod Security Standards als flexibler Einstieg in mehr Cluster-Sicherheit
Pod Security Standards lösen das alte PSP-Problem elegant: Statt einer komplexen, fehleranfälligen Konfiguration bekommst du drei klar definierte Profile, einen nativen Admission Controller ohne Zusatzinstallation und dank der drei unabhängig kombinierbaren Modi warn, audit und enforce einen sanften Migrationspfad, der bestehende Workloads nicht sofort aus dem Cluster wirft.
Wenn du bisher noch keine Pod Security Standards einsetzt, ist der pragmatischste erste Schritt schnell gemacht: Setze enforce clusterweit auf privileged oder direkt auf baseline, ergänze audit und warn für das nächststriktere Profil und beobachte über einige Wochen, welche Warnungen und Audit-Annotationen auflaufen. So bekommst du ein realistisches Bild davon, wie weit deine bestehenden Podkonfigurationen von einer sichereren Konfiguration entfernt sind. Das Alles ganz ohne das Risiko, produktive Workloads durch zu strikte Vorgaben lahmzulegen.
Für Anforderungen, die über die drei PSS-Profile hinausgehen – etwa organisationsspezifische Policies oder komplexere Validierungslogik – bieten sich anschließend Lösungen wie OPA Gatekeeper oder Kyverno an. Aber als Basisschutz, der in jedem Kubernetes-Cluster ab Werk verfügbar ist, gibt es aktuell kaum einen einfacheren Hebel als die Pod Security Standards, bei denen dir auch unser MyEngineer® gerne weiterhilft.
0 Kommentare