Schritt 1: Prüfen, dass alle Pods unter dem PSP 'ibm-privileged-psp' ausgeführt werden

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass alle Pods unter ibm-privileged-psp PSP ausgeführt werden.

Ein Unterschied zwischen Pod Security Admission und PodSecurityPolicies besteht darin, dass Pod Security Admission validiert wird, während die PodSecurityPolicies mutiert werden kann. Dies macht es wichtig, dass Pods die ibm-privileged-psp verwenden, die keine mutierende PSP ist, bevor Sie ein Upgrade durchführen. Da sowohl die Aufnahme der Pod-Sicherheit als auch die ibm-privileged-psp validiert werden, funktionieren Pods unter beiden gleich.

Wenn ein Pod beispielsweise momentan unter ibm-restricted-psp ausgeführt wird, können die Werte für fsGroup und supplementalGroups im Abschnitt securityContext des Pods auf 1 gesetzt werden, basierend auf dem Bereich MustRunAs im PSP. Die ibm-restricted-psp kann den Pod securityContext ändern. Solche Änderungen sind als Unterschied zwischen dem securityContext des aktiven Pods und dem securityContext in der Podvorlage der Bereitstellung oder einer ähnlichen Ressource sichtbar, die den Pod erstellt. Die ibm-privileged-psp ist nicht mutierend, sodass ein Pod, der unter ihr ausgeführt wird, möglicherweise mit unterschiedlichen Gruppen ausgeführt wird und möglicherweise nicht auf Daten zugreifen kann, die in einem vorhandenen PVC gespeichert sind.

1. Rufen Sie die Details aller Pods ab und überprüfen Sie deren PSPs.

   kubectl get pods -A -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u
   

2. Überprüfen Sie die Befehlsausgabe für alle PSPs, die nicht ibm-privileged-psp sind. Wenn Ihre Pods einen anderen PSP verwenden, müssen Sie Ihre Anwendung für die Verwendung von ibm-privileged-psp aktualisieren, bevor Sie ein Upgrade für Ihren Cluster durchführen. Wenn keine anderen PSPs aufgelistet werden, können Sie mit dem Upgrade fortfahren.

Ein Upgrade auf 1.25 wird nicht empfohlen, wenn in der Ausgabe ein anderer PSP als der ibm-privileged-psp PSP aufgeführt ist.

Schritt 2: Prüfen, ob die Clusterrollenbindung 'privileged-psp-user' die Standardkonfiguration verwendet

Führen Sie die folgenden Schritte durch, um zu überprüfen, ob die Rollenbindung des privileged-psp-user-Clusters die Standardkonfiguration verwendet. Dadurch wird sichergestellt, dass alle Servicekonten und Benutzer über die Clusterrollenbindung privileged-psp-user zur Verwendung von ibm-restricted-psp berechtigt sind.

Ihr Upgrade auf 1.25 schlägt fehl, wenn die Clusterrollenbindung nicht genau wie im folgenden Beispiel subjects gezeigt die Standardeinstellungen role und aufweist.

1. Rufen Sie die Details der privileged-psp-user-Clusterrollenbindung ab.

   kubectl get clusterrolebinding privileged-psp-user -o yaml
   

2. Überprüfen Sie die role und subjects in der Ausgabe. Wenn sich die Ausgabe vom folgenden Beispiel unterscheidet, führen Sie kein Upgrade auf 1.25durch. Wenn Ihre privileged-psp-user-Clusterrollenbindung dem folgenden Beispiel entspricht, können Sie mit dem Upgrade fortfahren.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     creationTimestamp: "2022-10-06T20:12:36Z"
     name: privileged-psp-user
     resourceVersion: "151862"
     uid: 15014736-94d2-4cba-a3a8-92dd36de453b
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: ibm-privileged-psp-user
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:nodes
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

Schritt 3: Prüfen, ob die Clusterrollenbindung 'restricted-psp-user' die Standardkonfiguration verwendet

Führen Sie die folgenden Schritte durch, um zu überprüfen, ob die Rollenbindung des restricted-psp-user-Clusters die Standardkonfiguration verwendet. Dadurch wird sichergestellt, dass alle Servicekonten und Benutzer über die Clusterrollenbindung restricted-psp-user zur Verwendung von ibm-restricted-psp berechtigt sind.

Ihr Upgrade auf 1.25 schlägt fehl, wenn die Clusterrollenbindung nicht die Standardwerte role und enthält subjects, wie im folgenden Beispiel gezeigt.

1. Details zur Rollenbindung des restricted-psp-user-Clusters abrufen

   kubectl get clusterrolebinding restricted-psp-user -o yaml
   

2. Überprüfen Sie die Befehlsausgabe. Aktualisieren Sie Ihren Cluster nicht auf Version 1.25, wenn die Clusterrollenbindung keine Standardeinstellungen für role und subjects enthält, wie im folgenden Beispiel gezeigt.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     creationTimestamp: "2022-10-06T20:13:10Z"
     name: restricted-psp-user
     resourceVersion: "151890"
     uid: 4edb362f-9933-48d7-95e2-f41cd9f4dead
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: ibm-restricted-psp-user
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:nodes
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

Schritt 4: Überprüfung auf PSPs anderer Anbieter alsIBM

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob Ihr Cluster PSPs anderer Anbieter alsIBM verwendet.

Das Upgrade auf Version 1.25 schlägt fehl, wenn die Befehlsausgabe zusätzliche PSPs zu denen im folgenden Beispiel enthält. Möglicherweise verfügen Sie über zusätzliche PSP von Anwendungen anderer Anbieter und benötigen Aktualisierungen für die Anwendungen oder arbeiten mit den Anwendungsanbietern zusammen, um die richtige Upgradestrategie für diese Anwendungen zu ermitteln.

1. Listen Sie Ihre Pod-Sicherheitsrichtlinien auf.

   kubectl get podsecuritypolicies -o name
   

2. Überprüfen Sie die Befehlsausgabe.

   Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
   podsecuritypolicy.policy/ibm-anyuid-hostaccess-psp
   podsecuritypolicy.policy/ibm-anyuid-hostpath-psp
   podsecuritypolicy.policy/ibm-anyuid-psp
   podsecuritypolicy.policy/ibm-privileged-psp
   podsecuritypolicy.policy/ibm-restricted-psp
   

3. Aktualisieren Sie Ihre Apps für die Verwendung der IBM PSPs.

Schritt 1: Zugangsberechtigung für Pod-Sicherheit in Ihrem 1.24-Cluster aktivieren

Aktivieren Sie die Zulassung zur Pod-Sicherheit im 1.24-Cluster. Dieser Befehl aktualisiert den Cluster-Master für die Verwendung der neuen Zugangskonfiguration für die Pod-Sicherheit. Es kann einige Minuten dauern, bis der Cluster-Master aktualisiert ist.

ibmcloud ks cluster master pod-security set --cluster <CLUSTER>

Schritt 2: Berechtigungen für Namensbereiche überprüfen

Überprüfen Sie die Berechtigungen für Namensbereiche in der externen Kubernetes-Dokumentation. Wenn Ihre Kubernetes-Berechtigungen durch IAM-Service-Rollen verwaltet werden, ist die Manager-Service-Rolle erforderlich, um Namespaces zu erstellen oder zu bearbeiten und Pod-Sicherheitslabels festzulegen.

• Berechtigungen für Namensbereiche prüfen

Schritt 3: PSPs vereinfachen und standardisieren

Bereinigen Sie Ihre Pod-Sicherheitskonfiguration, indem Sie die Schritte in der externen Kubernetes-Dokumentation ausführen. Ändern oder löschen Sie keine der folgenden PSPs: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp, ibm-anyuid-hostaccess-psp und ibm-restricted-psp.

• Vereinfachen und standardisieren PodSecurityPolicies

Schritt 4: Namensbereiche im Cluster aktualisieren

Aktualisieren Sie die Namensbereiche in Ihrem Cluster, indem Sie die Schritte in der externen Kubernetes-Dokumentation ausführen. Diese Schritte müssen für jeden Namensbereich im Cluster ausgeführt werden, der nicht von IBM Cloudverwaltet wird. Beachten Sie die Ausnahmen in diesem Abschnitt.

Löschen oder ändern Sie nicht die Pod-Sicherheitsbezeichnungen für die folgenden Namespaces, die von IBM Cloud: kube-system, ibm-system, ibm-operators verwaltet werden.

In Schritt 3.d. Umgehen Sie PodSecurity die Richtlinie der in diesem Schritt verlinkten externen Dokumentation und erstellen Sie nicht den vorgeschlagenen privilegierten PSP. Wenn Sie diese zusätzliche PSP erstellen, muss sie vor dem Upgrade auf Version 1.25 gelöscht werden, wie in den Upgrade-Anforderungen beschrieben. Verwenden Sie stattdessen den Befehl kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole ibm-privileged-psp-user --group system:serviceaccounts:$NAMESPACE, um eine RoleBinding für die Clusterrolle ibm-privileged-psp-user zu erstellen.

• Namensbereiche aktualisieren

Schritt 5: Erstellungsprozess für Namensbereiche überprüfen

Lesen Sie die Informationen in der externen Kubernetes-Dokumentation, um sicherzustellen, dass das Pod-Sicherheitsprofil auf alle neuen Namensbereiche angewendet wird, die in Ihrem Cluster erstellt werden.

• Prozesse zum Erstellen von Namensbereichen überprüfen

Schritt 6: Optional PSP-Funktion im Cluster inaktivieren

1. Inaktivieren Sie den PodSecurityPolicy-Zugangscontroller im Cluster. Dieser Befehl aktualisiert den Cluster-Master für die Verwendung der neuen Konfiguration.

   ibmcloud ks cluster master pod-security policy disable --cluster <cluster>
   

2. Warten Sie einige Minuten, bis die Aktualisierung des Cluster-Masters abgeschlossen ist.
3. Löschen Sie Ihre PSPs und alle zugehörigen Roles, ClusterRoles, RoleBindings und ClusterRoleBindings. Stellen Sie sicher, dass die von Ihnen gelöschten Komponenten keine anderen nicht zugehörigen Berechtigungen erteilen, die Sie möglicherweise an anderer Stelle benötigen. Löschen Sie die folgenden PSPs nicht: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp, ibm-anyuid-hostaccess-psp und ibm-restricted-psp. Löschen Sie nicht die folgenden ClusterRoles und ClusterRoleBindings: privileged-psp-user und restricted-psp-user.

Wenn Sie PSPs in Ihrem 1.24 Cluster wieder aktivieren müssen, führen Sie ibmcloud ks cluster master pod-security policy enable --cluster <cluster>. aus. Dieser Befehl aktualisiert den Cluster-Master für die Verwendung der PSP-Konfiguration.

Schritt 7: Optional Upgrade für Cluster durchführen

Aktualisieren Sie Ihren Cluster auf mindestens Version, 1.25 um Pod Security Admission zu verwenden. Oder behalten Sie Ihren Cluster in der Version 1.24 mit aktivierter Pod-Sicherheitszulassung, bis Sie für das Upgrade bereit sind.