Etape 1: Vérifiez que tous les pods s'exécutent sous la PSP ibm-privileged-psp

Procédez comme suit pour vous assurer que tous les pods s'exécutent sous la planification de maintenance préventive ibm-privileged-psp.

Une différence entre l'admission de sécurité de pod et PodSecurityPolicies est que l'admission de sécurité de pod est en cours de validation alors que le PodSecurityPolicies peut être en mutation. Il est donc important que les pods utilisent le ibm-privileged-psp, qui n'est pas un PSP de mutation, avant la mise à niveau. Etant donné que l'admission de sécurité de pod et le ibm-privileged-psp sont en cours de validation, les pods fonctionnent de la même manière sous l'un ou l'autre.

Par exemple, si un pod s'exécute actuellement sous ibm-restricted-psp, il peut définir fsGroup et supplementalGroups sur 1 dans la section securityContext du pod, en fonction de la plage MustRunAs dans la PSP. Le ibm-restricted-psp peut changer le pod securityContext. Ces modifications sont visibles comme une différence entre le securityContext du pod en cours d'exécution et le securityContext dans le modèle de pod du déploiement ou une ressource similaire qui crée le pod. Le ibm-privileged-psp n'ayant pas de faculté de mutation, un pod qui s'exécute sous lui peut s'exécuter avec des groupes différents et ne pas être en mesure d'accéder aux données stockées dans une réservation de volume persistant existante.

1. Obtenez les détails de tous les pods et vérifiez leurs PSP.

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

2. Consultez le résultat de la commande pour les PSP qui ne sont pas ibm-privileged-psp. Si vos pods utilisent une autre PSP, vous devez mettre à jour votre application pour utiliser ibm-privileged-psp avant de mettre à niveau votre cluster. Si aucun autre PSP n'est répertorié, vous pouvez poursuivre la mise à niveau.

La mise à niveau vers 1.25 n'est pas recommandée si la sortie répertorie un PSP autre que le PSP ibm-privileged-psp.

Etape 2: Vérifier que la liaison de rôle de cluster privileged-psp-user utilise la configuration par défaut

Procédez comme suit pour vérifier que la liaison de rôle de cluster privileged-psp-user utilise la configuration par défaut. Cela garantit que tous les comptes de service et les utilisateurs sont autorisés à utiliser le ibm-restricted-psp via la liaison de rôle de cluster privileged-psp-user.

Votre mise à niveau vers 1.25 échoue si la liaison de rôle de cluster ne possède pas les valeurs par défaut role et subjects exactement comme illustré dans l'exemple suivant.

1. Obtenez les détails de la liaison de rôle de cluster privileged-psp-user.

   kubectl get clusterrolebinding privileged-psp-user -o yaml
   

2. Passez en revue les fichiers role et subjects dans la sortie. Si la sortie est différente de l'exemple suivant, ne procédez pas à la mise à niveau vers 1.25. Si votre liaison de rôle de cluster privileged-psp-user correspond à l'exemple suivant, vous pouvez poursuivre la mise à niveau.

   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
   

Etape 3: Vérifier que la liaison de rôle de cluster restricted-psp-user utilise la configuration par défaut

Procédez comme suit pour vérifier que la liaison de rôle de cluster restricted-psp-user utilise la configuration par défaut. Cela garantit que tous les comptes de service et les utilisateurs sont autorisés à utiliser le ibm-restricted-psp via la liaison de rôle de cluster restricted-psp-user.

Votre mise à niveau vers 1.25 échoue si la liaison de rôle de cluster n'inclut pas les valeurs par défaut role et subjects, comme illustré dans l'exemple suivant.

1. Obtenir les détails de la liaison de rôle de cluster restricted-psp-user

   kubectl get clusterrolebinding restricted-psp-user -o yaml
   

2. Consultez la sortie de la commande. Ne mettez pas à niveau votre cluster vers la version 1.25 si la liaison de rôle de cluster n'inclut pas les paramètres par défaut pour role et subjects, comme illustré dans l'exemple suivant.

   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
   

Etape 4: Recherche de PSP non-IBM

Procédez comme suit pour vérifier si votre cluster utilise des PSP nonIBM.

La mise à niveau vers la version 1.25 échoue si la sortie de la commande inclut des PSP supplémentaires par rapport à ceux de l'exemple suivant. Il se peut que vous ayez des PSP supplémentaires provenant d'applications tierces et que vous ayez besoin de mises à jour des applications ou que vous travailliez avec les fournisseurs d'applications pour déterminer la stratégie de mise à niveau appropriée à utiliser pour ces applications.

1. Répertoriez vos politiques de sécurité de pod.

   kubectl get podsecuritypolicies -o name
   

2. Consultez la sortie de la commande.

   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. Mettez à jour vos applications pour utiliser les PSP IBM.

Etape 1: Activation de l'admission de la sécurité de pod dans votre cluster 1.24

Activez l'admission de la sécurité de pod dans votre cluster 1.24. Cette commande met à jour le maître cluster pour utiliser la nouvelle configuration d'admission de sécurité de pod. La mise à jour du maître de cluster peut prendre quelques minutes.

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

Etape 2: Passer en revue les droits d'espace de nom

Passez en revue les droits d'espace de nom dans la documentation Kubernetes externe. Si vos droits Kubernetes sont gérés par des rôles de service IAM, le rôle de service Manager est requis pour créer ou éditer des espaces de nom et pour définir des libellés de sécurité de pod.

• Vérification des droits d'espace de nom

Étape 3: Simplifier et normaliser les prestataires de services de paiement

Nettoyez votre configuration de sécurité de pod en suivant les étapes de la documentation Kubernetes externe. Ne modifiez ou ne supprimez pas les PSP suivants: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp, ibm-anyuid-hostaccess-psp et ibm-restricted-psp.

• Simplifier et normaliser PodSecurityPolicies

Etape 4: Mise à jour des espaces de nom dans votre cluster

Mettez à jour les espaces de nom dans votre cluster en suivant les étapes de la documentation Kubernetes externe. Ces étapes doivent être effectuées sur chaque espace de nom du cluster qui n'est pas géré par IBM Cloud. Notez les exceptions incluses dans cette section.

Ne supprimez pas ou ne modifiez pas les libellés de sécurité de pod pour les espaces de nom suivants qui sont gérés par IBM Cloud: kube-system, ibm-system, ibm-operators.

A l'étape 3.d. Ignorez PodSecurity Policy de la documentation externe liée à cette étape, ne créez pas le PSP privilégié suggéré. Si vous créez ce PSP supplémentaire, il doit être supprimé avant la mise à niveau vers la version 1.25, comme indiqué dans la configuration requise pour la mise à niveau. A la place, utilisez la commande suivante pour créer un RoleBinding pour le rôle de cluster ibm-privileged-psp-user : kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole ibm-privileged-psp-user --group system:serviceaccounts:$NAMESPACE.

• Mettre à jour les espaces de nom

Etape 5: Passez en revue le processus de création d'espace de nom

Consultez les informations de la documentation Kubernetes externe pour vous assurer que le profil de sécurité de pod est appliqué à tous les nouveaux espaces de nom créés dans votre cluster.

• Passer en revue les processus de création d'espace de nom

Etape 6: Facultatif. Désactiver la fonction PSP dans le cluster

1. Désactivez le contrôleur d'admission PodSecurityPolicy dans le cluster. Cette commande met à jour le maître cluster pour utiliser la nouvelle configuration.

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

2. Attendez quelques minutes que la mise à jour du maître cluster soit terminée.
3. Supprimez vos PSP et les Roles, ClusterRoles, RoleBindings et ClusterRoleBindings associés. Assurez-vous que les composants que vous supprimez n'accordent pas d'autres droits non associés dont vous pourriez avoir besoin ailleurs. Ne supprimez pas les PSP suivants: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp, ibm-anyuid-hostaccess-psp et ibm-restricted-psp. Ne supprimez pas les fichiers ClusterRoles et ClusterRoleBindings suivants: privileged-psp-user et restricted-psp-user.

Si vous devez réactiver les PSP dans votre cluster 1.24, exécutez ibmcloud ks cluster master pod-security policy enable --cluster <cluster>. Cette commande met à jour le maître cluster pour utiliser la configuration PSP.

Etape 7: Facultatif. Mise à niveau de votre cluster

Mettez à niveau votre cluster vers la version 1.25 pour utiliser l'admission de la sécurité de pod. Ou bien, conservez votre cluster à la version 1.24 avec l'admission de la sécurité de pod activée jusqu'à ce que vous soyez prêt à effectuer la mise à niveau.