步骤 1: 检查是否所有 pod 都在 ibm-privileged-psp PSP 下运行

完成以下步骤以确保所有 pod 都在 ibm-privileged-psp PSP 下运行。

“Pod 安全许可”与 PodSecurityPolicies 之间的一个区别在于，“Pod 安全许可”正在验证，而 PodSecurityPolicies 可能会发生突变。 这使得 Pod 在升级之前使用 ibm-privileged-psp(这不是一个突变的 PSP) 非常重要。 由于 Pod 安全许可和 ibm-privileged-psp 都在验证，因此 pod 在任一 pod 下的工作方式相同。

例如，如果 pod 当前正在 ibm-restricted-psp 下运行，那么它可能会根据 PSP 中的 MustRunAs 范围，在 pod securityContext 部分中将 fsGroup 和 supplementalGroups 设置为 1。 ibm-restricted-psp 可以更改吊舱 securityContext。 此类更改可视为正在运行的 pod 的 securityContext 与用于创建 pod 的部署或类似资源的 pod 模板中的 securityContext 之间的差异。 ibm-privileged-psp 未发生突变，因此在其下运行的 pod 可能与不同的组一起运行，并且可能无法访问存储在现有 PVC 中的数据。

1. 获取所有 pod 的详细信息，并检查其 PSP。

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

2. 查看非 ibm-privileged-psp 的任何 PSP 的命令输出。 如果 pod 正在使用其他 PSP，那么在升级集群之前，必须更新应用程序以使用 ibm-privileged-psp。 如果未列出任何其他 PSP，那么可以继续升级。

如果输出列出了除 ibm-privileged-psp PSP 以外的 PSP，那么建议不要升级到 1.25。

步骤 2: 验证 privileged-psp-user 集群角色绑定是否使用缺省配置

完成以下步骤以验证 privileged-psp-user 集群角色绑定是否使用缺省配置。 这将确保所有服务帐户和用户都有权通过 privileged-psp-user 集群角色绑定来使用 ibm-restricted-psp。

如果集群角色绑定没有正好如以下示例中所示的缺省 role 和 subjects，那么升级到 1.25 将失败。

1. 获取详细信息 privileged-psp-user 集群角色绑定。

   kubectl get clusterrolebinding privileged-psp-user -o yaml
   

2. 查看输出中的 role 和 subjects。 如果输出与以下示例不同，请不要升级到 1.25。 如果 privileged-psp-user 集群角色绑定与以下示例匹配，那么可以继续升级。

   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
   

步骤 3: 验证 restricted-psp-user 集群角色绑定是否使用缺省配置

完成以下步骤以验证 restricted-psp-user 集群角色绑定是否使用缺省配置。 这将确保所有服务帐户和用户都有权通过 restricted-psp-user 集群角色绑定来使用 ibm-restricted-psp。

如果集群角色绑定不包含缺省 role 和 subjects，那么升级到 1.25 将失败，如以下示例中所示。

1. 获取 restricted-psp-user 集群角色绑定的详细信息

   kubectl get clusterrolebinding restricted-psp-user -o yaml
   

2. 查看命令输出。 如果集群角色绑定不包含 role 和 subjects 的缺省设置，请不要将集群升级到 V 1.25，如以下示例中所示。

   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
   

步骤 4: 正在检查非IBM PSP

完成步骤以检查集群是否使用非IBM PSP。

如果命令输出包含除以下示例中的 PSP 之外的其他 PSP，那么升级到 V 1.25 将失败。 您可能具有来自第三方应用程序的其他 PSP，并且需要更新应用程序或与应用程序供应商一起确定要用于这些应用程序的正确升级策略。

1. 列出 pod 安全策略。

   kubectl get podsecuritypolicies -o name
   

2. 查看命令输出。

   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. 更新应用程序以使用 IBM PSP。

步骤 1: 在 1.24 集群中启用 Pod 安全性许可

在 1.24 集群中启用 Pod 安全性许可。 此命令更新集群主节点以使用新的 Pod 安全许可配置。 群集主控程序更新可能需要几分钟时间。

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

步骤 2: 复审名称空间许可权

查看外部 Kubernetes 文档中的名称空间许可权。 如果 Kubernetes 许可权由 IAM 服务角色管理，那么需要 Manager 服务角色来创建或编辑名称空间以及设置 pod 安全标签。

• 复审名称空间许可权

步骤 3: 简化和标准化 PSP

遵循外部 Kubernetes 文档中的步骤来清除 Pod 安全性配置。 请勿 修改或删除以下任何 PSP: ibm-privileged-psp，ibm-anyuid-psp，ibm-anyuid-hostpath-psp，ibm-anyuid-hostaccess-psp 和 ibm-restricted-psp。

• 简化和标准化 PodSecurityPolicies

步骤 4: 更新集群中的名称空间

通过遵循外部 Kubernetes 文档中的步骤来更新集群中的名称空间。 必须在集群中不受 IBM Cloud管理的每个名称空间上执行这些步骤。 请注意本节中包含的异常。

请勿删除或修改由 IBM Cloud管理的以下名称空间的 Pod 安全标签: kube-system，ibm-system 和 ibm-operators。

在步骤 3.d中。 绕过此步骤中链接的外部文档的 PodSecurity 策略，不创建建议的特权 PSP。 如果您创建此附加 PSP，那么必须在升级到 V 1.25之前将其删除，如 升级需求 中所述。 请改为使用以下命令来创建 RoleBinding 到 ibm-privileged-psp-user 集群角色: kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole ibm-privileged-psp-user --group system:serviceaccounts:$NAMESPACE。

• 更新名称空间

步骤 5: 复审名称空间创建过程

查看外部 Kubernetes 文档中的信息，以确保将 Pod 安全概要文件应用于集群中创建的任何新名称空间。

• 复审名称空间创建进程

步骤 6: 可选。 在集群中禁用 PSP 功能

1. 在集群中禁用 PodSecurityPolicy 许可控制器。 此命令将更新集群主节点以使用新配置。

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

2. 等待几分钟以使集群主节点更新完成。
3. 删除 PSP 以及任何关联的 Roles，ClusterRoles，RoleBindings 和 ClusterRoleBindings。 确保您删除的组件不会授予您在其他位置可能需要的任何其他不相关许可权。 请勿 删除以下 PSP: ibm-privileged-psp，ibm-anyuid-psp，ibm-anyuid-hostpath-psp，ibm-anyuid-hostaccess-psp 和 ibm-restricted-psp。 请勿 删除以下 ClusterRoles 和 ClusterRoleBindings: privileged-psp-user 和 restricted-psp-user。

如果需要在 1.24 集群中重新启用 PSP，请运行 ibmcloud ks cluster master pod-security policy enable --cluster <cluster>。 此命令更新集群主节点以使用 PSP 配置。

步骤 7: 可选。 升级集群

将集群升级到 V 1.25 以使用 Pod 安全许可。 或者，保持集群处于 1.24 版本，并启用 Pod 安全许可，直到您准备好升级为止。