Entfernen der Pod-Sicherheitsrichtlinie (PSP) – Häufig gestellte Fragen - Amazon EKS

Helfen Sie mit, diese Seite zu verbessern

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle zu verbessern.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Entfernen der Pod-Sicherheitsrichtlinie (PSP) – Häufig gestellte Fragen

Die PodSecurityPolicy war in Kubernetes1.21 veraltet und wurde aus Kubernetes1.25 entfernt. Wenn Sie PodSecurityPolicy in Ihrem Cluster verwenden, müssen Sie zu den integrierten Kubernetes Pod-Sicherheitsstandards (PSS) oder zu einer policy-as-code Lösung migrieren, bevor Sie Ihren Cluster auf Version aktualisieren1.25, um Unterbrechungen Ihrer Workloads zu vermeiden. Wählen Sie eine häufig gestellte Frage aus, um mehr zu erfahren.

PodSecurityPolicy ist ein integrierter Zulassungscontroller, mit dem ein Cluster-Administrator sicherheitsrelevante Aspekte der Pod Spezifikation steuern kann. Wenn ein Pod die Anforderungen seiner PSP erfüllt, wird der Pod wie gewohnt in den Cluster aufgenommen. Wenn ein Pod die PSP-Anforderungen nicht erfüllt, wird der Pod abgelehnt und kann nicht ausgeführt werden.

Dies ist eine Upstream-Änderung im Kubernetes-Projekt und keine Änderung in Amazon EKS. PSP war in Kubernetes 1.21 veraltet und wurde in Kubernetes 1.25 entfernt. Die Kubernetes-Community hat schwerwiegende Probleme mit der Benutzerfreundlichkeit von PSP identifiziert. Dazu gehörten die versehentliche Erteilung umfassenderer Genehmigungen als beabsichtigt und Schwierigkeiten bei der Überprüfung, welche PSPs in einer bestimmten Situation anwenden. Diese Probleme konnten nicht behoben werden, ohne grundlegende Änderungen vorzunehmen. Dies ist der Hauptgrund, warum die Kubernetes-Community beschlossen hat, PSP zu entfernen.

Zur Überprüfung, ob Sie die PSPs in Ihrem Cluster verwenden, könnten Sie den folgenden Befehl ausführen:

kubectl get psp

Führen Sie den folgenden Befehl aus, um die Pods anzuzeigen, auf die sich die PSPs in Ihrem Cluster auswirken. Dieser Befehl gibt den Pod-Namen, den Namespace und die PSPs aus:

kubectl get pod -A -o jsonpath='{range.items[?(@.metadata.annotations.kubernetes\.io/psp)]}{.metadata.name}{"\t"}{.metadata.namespace}{"\t"}{.metadata.annotations.kubernetes\.io/psp}{"\n"}'

Bevor Sie Ihren Cluster auf 1.25 aktualisieren, müssen Sie Ihre PSPs auf eine der folgenden Alternativen migrieren:

  • Kubernetes PSS.

  • P-olicy-as-code Lösungen aus der Kubernetes Umgebung.

Als Reaktion auf die PSP-Einstellung und die anhaltende Notwendigkeit, die Pod-Sicherheit von Anfang an zu kontrollieren, hat die Kubernetes-Community eine integrierte Lösung mit (PSS) und Pod Security Admission (PSA) entwickelt. Der PSA-Webhook implementiert die Steuerelemente, die in der PSS definiert sind.

Die bewährten Methoden für die Migration der PSPs zur integrierten Version der PSS finden Sie im Leitfaden zu bewährten Methoden für Amazon EKS.. Wir empfehlen außerdem, unseren Block zur Implementation von Pod-Sicherheitsstandards in Amazon EKS zu lesen. Weitere Referenzen umfassen die Migration von PodSecurityPolicy zum integrierten PodSecurity Zulassungscontroller und die Zuordnung PodSecurityPolicies zu Pod-Sicherheitsstandards.

P-olicy-as-code Lösungen bieten Integritätsschutz als Leitfaden für Cluster-Benutzer und verhindern unerwünschte Verhaltensweisen durch vorgeschriebene automatisierte Kontrollen. P-olicy-as-code Lösungen verwenden in der Regel Kubernetes Dynamic Admission Controllers, um den Anforderungsfluss des Kubernetes API-Servers mithilfe eines Webhook-Aufrufs abzufangen. P-olicy-as-code Lösungen mutieren und validieren Anforderungsnutzlasten basierend auf Richtlinien, die als Code geschrieben und gespeichert werden.

Für sind mehrere Open-Source- policy-as-code Lösungen verfügbarKubernetes. Bewährte Methoden für die Migration PSPs zu einer policy-as-code Lösung finden Sie im Abschnitt Policy-as-code der Pod-Sicherheitsseite auf GitHub.

Amazon-EKS-Cluster mit Kubernetes-Version 1.13 oder höher verfügen über eine standardmäßige PSP mit dem Namen eks.privileged. Diese Richtlinie wurde in 1.24 und früheren Clustern erstellt. Sie wird nicht in 1.25 und späteren Clustern verwendet. Amazon EKS migriert diese PSP automatisch zu einer PSS-basierten Durchsetzung. Von Ihrer Seite aus ist keine Aktion erforderlich.

Nein. Neben eks.privileged, eine von Amazon EKS erstellte PSP, werden beim Upgrade keine Änderungen an anderen PSPs in Ihrem Cluster vorgenommen, wenn Sie auf 1.25 aktualisieren.

Nein. Amazon EKS verhindert ein Cluster-Update auf die Version 1.25 nicht, wenn Sie noch nicht von der PSP migriert haben.

Wenn ein Cluster mit einer PSP auf Kubernetes-Version 1.25 aktualisiert wird, erkennt der API-Server die PSP-Ressource in 1.25 nicht. Dies kann dazu führen, dass Pods falsche Sicherheitsbereiche erhalten. Eine vollständige Liste der Auswirkungen finden Sie unter Migrieren von PodSecurityPolicy zum integrierten PodSecurity Zulassungscontroller .

Wir erwarten keine spezifischen Auswirkungen auf Windows-Workloads. PodSecurityContext hat ein Feld namens windowsOptions in der PodSpec v1 API für Windows Pods. Dies verwendet PSS in Kubernetes 1.25. Weitere Informationen und bewährte Methoden zur Durchsetzung PSS von Windows-Workloads finden Sie im Leitfaden zu bewährten Methoden für Amazon EKS und in der Kubernetes-Dokumentation.