Von einer älteren Version migrieren Pod Sicherheitsrichtlinien (PSP) - Amazon EKS

Helfen Sie mit, diese Seite 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.

Möchten Sie zu diesem Benutzerhandbuch beitragen? Wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet. Ihre Beiträge werden dazu beitragen, dass unser Benutzerhandbuch für alle besser wird.

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.

Von einer älteren Version migrieren Pod Sicherheitsrichtlinien (PSP)

PodSecurityPolicywar in Kubernetes 1.21 veraltet und wurde entfernt in Kubernetes 1.25. Wenn Sie PodSecurityPolicy in Ihrem Cluster verwenden, müssen Sie auf das integrierte System migrieren Kubernetes Sicherheitsstandards für Pods (PSS) oder auf eine policy-as-code Lösung, bevor Sie Ihren Cluster auf Version *1.25 aktualisieren, um Unterbrechungen Ihrer Workloads zu vermeiden.* Wählen Sie eine häufig gestellte Frage aus, um mehr zu erfahren.

PodSecurityPolicyist ein integrierter Zugangscontroller, der es einem Clusteradministrator ermöglicht, sicherheitsrelevante Aspekte von zu kontrollieren Pod Spezifikation. Wenn ein Pod erfüllt die Anforderungen seiner PSP, der Pod wird wie gewohnt in den Cluster aufgenommen. Wenn ein Pod entspricht nicht dem PSP Anforderungen, die Pod wird abgelehnt und kann nicht ausgeführt werden.

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

Um zu überprüfen, ob Sie verwenden PSPs In Ihrem Cluster können Sie den folgenden Befehl ausführen:

kubectl get psp

Um das zu sehen Pods dass der PSPs Führen Sie in Ihrem Cluster den folgenden Befehl aus. Dieser Befehl gibt Folgendes aus Pod Name, Namespace und PSPs:

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

Bevor Sie Ihren Cluster auf aktualisieren1.25, müssen Sie Ihren migrieren PSPs zu einer dieser Alternativen:

  • Kubernetes PSS.

  • Policy-as-code Lösungen von Kubernetes Umwelt.

Als Antwort auf die PSP Vernachlässigung und der anhaltende Kontrollbedarf Pod Sicherheit von Anfang an, die Kubernetes Die Community hat eine integrierte Lösung mit (PSS) und Pod Security Admission (PSA) entwickelt. Der PSA-Webhook implementiert die Steuerelemente, die in der definiert sind PSS.

Sie können sich über bewährte Methoden für die Migration informieren PSPs zum integrierten PSS im EKS Best Practices Guide. Wir empfehlen außerdem, unseren Block zur Implementation von Pod-Sicherheitsstandards in Amazon EKS zu lesen. Zu den weiteren Referenzen gehören PodSecurityPolicy die Migration vom integrierten PodSecurity Admission Controller und PodSecurityPolicies die Zuordnung zu Pod-Sicherheitsstandards.

Policy-as-code Die Lösungen bieten Leitplanken zur Orientierung der Cluster-Benutzer und verhindern unerwünschtes Verhalten durch vorgeschriebene automatische Kontrollen. Policy-as-codeLösungen verwenden in der Regel Kubernetes Dynamic Admission Controller, um das abzufangen Kubernetes API-Server-Anforderungsfluss mithilfe eines Webhook-Aufrufs. Policy-as-codeLösungen mutieren und validieren Anforderungs-Payloads auf der Grundlage von Richtlinien, die als Code geschrieben und gespeichert wurden.

Es gibt mehrere policy-as-code Open-Source-Lösungen für Kubernetes. Um sich über bewährte Methoden für die Migration zu informieren PSPs Eine policy-as-code Lösung finden Sie im olicy-as-code Abschnitt P auf der Pod Security-Seite unter GitHub.

Amazon EKS-Cluster mit Kubernetes Version 1.13 oder höher haben eine Standardeinstellung PSP das ist benannteks.privileged. Diese Richtlinie wurde in 1.24 und früheren Clustern erstellt. Es wird in 1.25 und späteren Clustern nicht verwendet. Amazon EKS migriert dies automatisch PSP zu einem PSSgestützte Durchsetzung. Von Ihrer Seite aus ist keine Aktion erforderlich.

Nein. Außerdemeks.privileged, was ist ein PSP erstellt von Amazon EKS, es werden keine Änderungen an anderen vorgenommen PSPs in Ihrem Cluster, wenn Sie ein Upgrade auf durchführen1.25.

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

Wenn ein Cluster, der enthält PSP wurde aktualisiert auf Kubernetes Version1.25, der API-Server erkennt die nicht PSP Ressource in1.25. Dies könnte dazu führen Pods falsche Sicherheitsbereiche werden angezeigt. Eine vollständige Liste der Auswirkungen finden Sie unter Migration vom integrierten Admission Controller PodSecurityPolicy zum integrierten PodSecurity Admission Controller.

Wir erwarten keine spezifischen Auswirkungen auf Windows-Workloads. PodSecurityContext hat ein Feld namens windowsOptions in der PodSpec v1 API für Windows Pods. Das benutzt PSS in Kubernetes 1.25. Weitere Informationen und bewährte Verfahren zur Durchsetzung PSS Informationen zu Windows-Workloads finden Sie im EKS Best Practices Guide und Kubernetes Dokumentation.