Von PodSecurityPolicy zum PodSecurity-Admission-Controller migrieren.

Autopilot Standard

Auf dieser Seite erfahren Sie, wie Sie weiterhin viele Sicherheitskontrollen auf Pod-Ebene in Ihren GKE-Clustern (Google Kubernetes Engine) erzwingen können, indem Sie von PodSecurityPolicy zum PodSecurity-Admission-Controller migrieren.

Überblick

PodSecurityPolicy war ein Kubernetes-Admission-Controller, mit dem Sie Sicherheitskontrollen auf Pod-Ebene wie die Kubernetes Pod-Sicherheitsstandards erzwingen können. Damit können Sie die Sicherheitskonfiguration der bereitgestellten Arbeitslasten genau steuern. Das Kubernetes-Projekt hat PodSecurityPolicy eingestellt und die Funktion vollständig in Kubernetes v1.25 entfernt.

Wenn Sie PodSecurityPolicy derzeit in Ihren GKE-Clustern verwenden, deaktivieren Sie das Feature, bevor Sie ein Upgrade auf GKE-Version 1.25 und höher ausführen.

Weitere Informationen zur Einstellung und Entfernung von PodSecurityPolicy finden Sie unter PodSecurityPolicy verworfen.

PodSecurity und PodSecurityPolicy

Der PodSecurity-Admission-Controller ist standardmäßig in Clustern verfügbar, die auf den folgenden GKE-Versionen ausgeführt werden:

Version 1.25 oder höher: stabile Version
Version 1.23 und Version 1.24: Beta

Mit PodSecurity können Sie die Richtlinien erzwingen, die in den Pod-Sicherheitsstandards für Ihre bereitgestellten Arbeitslasten definiert sind. Mit PodSecurity können Sie nach der Migration aus PodSecurityPolicy weiterhin empfohlene Sicherheitskonfigurationen auf Pod-Ebene in Ihren Clustern implementieren. Im Gegensatz zu PodSecurityPolicy unterstützt PodSecurity keine benutzerdefinierten Konfigurationen.

Anforderungen und Einschränkungen

PodSecurity ist in der Betaversion in GKE 1.23 und 1.24 und in der stabilen Version von GKE 1.25 und höher verfügbar.
PodSecurity beendet keine Pods, die bereits auf Ihren Knoten ausgeführt werden, auch wenn sie gegen die angewendete Richtlinie verstoßen.
PodSecurity mutiert keine Felder. Wenn Sie mutierende Felder in Ihrer PodSecurityPolicy verwenden, ändern Sie die Pod-Spezifikation so, dass diese Felder beim Bereitstellen der Arbeitslasten vorhanden sind.

Vorbereitung

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Achten Sie darauf, dass Sie einen GKE Autopilot- oder Standardcluster mit Version 1.23 oder höher haben.
- Registrieren Sie sich im Fall von Autopilot-Clustern in einer Release-Version, in der die Standardversion 1.23 oder höher ist.
- Registrieren Sie sich im Fall von Standardclustern in einer Release-Version oder aktualisieren Sie den Cluster auf eine bestimmte Version.
Prüfen Sie Ihre PodSecurityPolicy-Ressourcen auf mutierende Feldkonfigurationen. Fügen Sie diese Felder den Pod-Manifesten hinzu, damit alle Arbeitslasten, die bereits auf Ihren Knoten ausgeführt werden, einer in den Pod-Sicherheitsstandards definierten Richtlinie entsprechen. Eine Anleitung finden Sie unter Pod-Sicherheitsrichtlinien vereinfachen und standardisieren.

PodSecurity-Admission-Controller im Cluster konfigurieren

Der PodSecurity-Admission-Controller erzwingt die Pod-Sicherheitsstandards auf Namespace-Ebene. Sie müssen den Controller so konfigurieren, dass eine der durch die Pod-Sicherheitsstandards definierten Richtlinien in jedem Namespace erzwungen wird. Die folgenden Richtlinien sind verfügbar:

Eingeschränkt: die restriktivste Richtlinie. Entspricht den Best Practices zur Pod-Härtung.
Baseline: Minimal restriktive Richtlinie, die bekannte Rechteausweitungen verhindert. Erlaubt alle Standardwerte für Felder in Pod-Spezifikationen.
Privilegiert: Uneingeschränkte Richtlinie, die alles zulässt, einschließlich bekannter Rechteausweitungen. Wenden Sie diese Richtlinie mit Vorsicht an.

Führen Sie in jedem Namespace in Ihrem Cluster die folgenden Schritte aus, um Ihre PodSecurityPolicy-Konfiguration zum Admission-Controller PodSecurity zu migrieren. Diese Schritte werden in den folgenden Abschnitten ausführlich beschrieben.

Wenden Sie die Richtlinie Eingeschränkt im dry-run-Modus auf den Namespace an und prüfen Sie auf Verstöße.
Wenn Ihre Pods gegen die Richtlinie Eingeschränkt verstoßen, wenden Sie die weniger einschränkende Baseline-Richtlinie im dry-run-Modus auf den Namespace an und prüfen Sie auf Verstöße.
Wenn Ihre Pods gegen die Richtlinie Baseline verstoßen, ändern Sie Ihre Pod-Spezifikationen, um die Verstöße zu beheben.
Wenn die Richtlinie Baseline keine Verstöße mehr zurückgibt, wenden Sie die Richtlinie im Modus enforce auf den Namespace an.

Führen Sie diese Schritte in einer Staging-Umgebung aus, um potenzielle Ausfallzeiten zu vermeiden, wenn PodSecurity neue Pods ablehnt. Alternativ können Sie die identifizierte Richtlinie im audit-Modus anstelle des enforce-Modus anwenden und Ihre Audit-Logs prüfen, um potenzielle abgelehnte Pods zu finden.

Im Modus audit wird die Richtlinie nicht erzwungen. GKE stellt die Pods bereit und fügt den GKE-Audit-Logs Einträge hinzu.

Alle Namespaces in Ihrem Cluster auflisten

Rufen Sie eine Liste aller Namespaces in Ihrem Cluster ab. Wiederholen Sie die Schritte in den folgenden Abschnitten für jeden Namespace in der Liste:

kubectl get ns

In den folgenden GKE-Versionen ignoriert GKE Richtlinien, die Sie auf den Namespace kube-system anwenden:

1.23.6-gke.1900 und höher
1.24.0-gke.1200 und höher

Vermeiden Sie in früheren GKE-Versionen das Erzwingen von Richtlinien in kube-system.

Jede Richtlinie der Pod-Sicherheitsstandards im Probelaufmodus anwenden

In den folgenden Schritten wenden Sie jede Richtlinie im dry-run-Modus an, beginnend mit der restriktivsten eingeschränkten Richtlinie. Wenn die Ausgabe eine Warnung anzeigt, ändern Sie entweder die Verstoß-Pod-Spezifikation, um die Richtlinie einzuhalten, oder versuchen Sie es mit der weniger restriktiven Baseline-Richtlinie. Wenn in der Ausgabe keine Warnung angezeigt wird, können Sie die Richtlinie Baseline ohne dry-run-Modus anwenden.

Wenden Sie die Richtlinie Eingeschränkt im dry-run-Modus an:
```
kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=restricted
```
Wenn ein Pod im Namespace gegen die Eingeschränkt-Richtlinie verstößt, sieht die Ausgabe etwa so aus:
```
Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "restricted:latest"
namespace/NAMESPACE labeled
```
Wenn in der Richtlinie Eingeschränkt eine Warnung angezeigt wird, ändern Sie Ihre Pods, um den Verstoß zu beheben, und führen Sie den Befehl noch einmal aus. Alternativ können Sie im folgenden Schritt die weniger restriktive Baseline-Richtlinie ausprobieren.

Wenden Sie die Richtlinie Baseline im Modus dry-run an:

kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=baseline

Wenn ein Pod im Namespace gegen die Basline-Richtlinie verstößt, sieht die Ausgabe etwa so aus:

Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "baseline:latest"
namespace/NAMESPACE labeled

Wenn Ihre Pods gegen die Baseline-Richtlinie verstoßen, ändern Sie Ihre Pods, um die Verstöße zu beheben, und wiederholen Sie diesen Schritt, bis GKE keine Warnung mehr anzeigt.

Richtlinie für einen Namespace erzwingen

Wenn Sie die Richtlinie ermitteln, die für einen Namespace funktioniert, wenden Sie die Richtlinie auf den Namespace im Modus enforce an:

kubectl label --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=POLICY

Ersetzen Sie POLICY durch den Namen der Richtlinie, entweder restricted, baseline oder privileged.

Wiederholen Sie die vorherigen Schritte für jeden Namespace in Ihrem Cluster.

PodSecurityPolicy-Feature im Cluster deaktivieren

Nachdem Sie den PodSecurity-Admission-Controller für jeden Namespace in Ihrem Cluster konfiguriert haben, deaktivieren Sie das PodSecurityPolicy-Feature:

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-pod-security-policy

Ersetzen Sie dabei CLUSTER_NAME durch den Namen Ihres GKE-Clusters.

Wenn Sie Ihren Cluster auf GKE Version 1.25 aktualisieren, entfernt GKE automatisch alle verbleibenden PodSecurityPolicy-Objekte, einschließlich der von GKE und Policy Controller hinzugefügten Objekte sowie alle PodSecurityPolicy-Objekte, die Sie zuvor definiert haben.

Empfehlungen

Versuchen Sie möglichst, die eingeschränkte Richtlinie einzuhalten. Prüfen Sie Ihre Anwendungen, um festzustellen, ob die Konfiguration weiter gehärtet werden kann.
Sie können den Pod-Sicherheitsmodus für eine bestimmte Kubernetes-Nebenversion sperren, indem Sie den kubectl label-Befehlen in den vorherigen Schritten das Label pod-security.kubernetes.io/MODE-version: VERSION hinzufügen. Ersetzen Sie VERSION durch die Kubernetes-Versionsnummer, z. B. v1.24.
Prüfen Sie nach dem Deaktivieren des PodSecurityPolicy-Features Ihre laufenden Anwendungen, um in Erfahrung zu bringen, ob die Sicherheitskonfiguration Unterbrechungen oder Lücken aufweist.
Nachdem Sie PodSecurity konfiguriert haben, aktualisieren Sie den Namespace-Erstellungsprozess, um automatisch ein Label PodSecurity auf alle neuen Namespaces anzuwenden. Weitere Informationen finden Sie unter Namespace-Erstellungsprozess prüfen.