Migración de PSP a Admisión de seguridad de pod

La admisión de seguridad de pods sustituye a las políticas de seguridad de pods (PSP) en clústeres que ejecutan la versión 1.25 o posterior. Dependiendo de la configuración de su PSP, es posible que deba realizar ciertas acciones antes de actualizar su clúster de la versión 1.24 a 1.25.

El clúster debe cumplir determinados requisitos de configuración de PSP para poder actualizar de la versión 1.24 a 1.25. Si el clúster no cumple estos requisitos, la actualización se bloquea. Realice los pasos siguientes para comprobar los PSP personalizados y eliminarlos.

  • Si no ha personalizado o modificado PSP en el clúster, es probable que pueda actualizar el clúster. Sin embargo, se recomienda revisar los requisitos para asegurarse de que no es necesario modificar la configuración de PSP antes de actualizar el clúster.
  • Si ha personalizado o modificado PSP en el clúster, incluida la creación de sus propios PSP, la instalación de aplicaciones que crean PSP o el cambio de enlaces de rol de clúster para restringir el uso de determinados PSP, debe modificar la configuración para cumplir los requisitos para actualizar el clúster.

Antes de comenzar, revise la información que se encuentra en Decida si la admisión de seguridad de pods es adecuada para usted en la Kubernetes documentación para familiarizarse con las diferencias entre los PSP y la admisión de seguridad de pods.

Requisitos de actualización

Puede actualizar el clúster si la configuración del clúster cumple los requisitos siguientes. Estos requisitos garantizan que los pods se ejecuten correctamente bajo la configuración de admisión de seguridad de pod predeterminada que se proporciona en los clústeres que ejecutan la versión 1.25. Si no se cumplen estos requisitos, el clúster no se puede actualizar a menos que realice pasos de migración adicionales.

  • Todos los pods se ejecutan bajo el PSP de ibm-privileged-psp.
  • El enlace de rol de clúster de privileged-psp-user utiliza la configuración predeterminada.
  • El enlace de rol de clúster de restricted-psp-user utiliza la configuración predeterminada.
  • Solo están presentes los siguientes PSP proporcionados por IBM Cloud y no se han configurado PSP adicionales.
    • ibm-privileged-psp
    • ibm-anyuid-psp
    • ibm-anyuid-hostpath-psp
    • ibm-anyuid-hostaccess-psp
    • ibm-restricted-psp

Si el clúster cumple estos requisitos, los pods utilizan un PSP que permite pods con privilegios. Sin embargo, el cumplimiento de estos requisitos no significa que todos los pods sean privilegiados.

Si ha creado sus propios PSP, las aplicaciones instaladas que crean PSP o ha cambiado los enlaces de rol de clúster para restringir el uso de ibm-privileged-psp, debe modificar la configuración para cumplir los requisitos listados antes de poder actualizar el clúster. Si utiliza controladores de admisión de políticas de seguridad de terceros, el clúster puede seguir cumpliendo estos requisitos siempre que todos los controladores funcionen correctamente dentro de la configuración de PSP.

Realice los pasos siguientes para confirmar que la configuración de PSP de clúster cumple los requisitos. Si se cumplen todos los requisitos, puede actualizar el clúster a la versión 1.25.

Paso 1: Comprobar que todos los pods se ejecutan bajo el PSP ibm-privileged-psp

Complete los pasos siguientes para asegurarse de que todos los pods se ejecutan bajo el PSP de ibm-privileged-psp.

Una diferencia entre la Admisión de seguridad de pod y PodSecurityPolicies es que la Admisión de seguridad de pod se está validando mientras que el PodSecurityPolicies puede estar mutando. Esto hace que sea importante que los pods utilicen ibm-privileged-psp, que no es un PSP mutante, antes de actualizar. Debido a que tanto Pod Security Admission como ibm-privileged-psp están validando, los pods funcionan igual bajo cualquiera de ellos.

Por ejemplo, si un pod se está ejecutando actualmente bajo ibm-restricted-psp, puede establecer fsGroup y supplementalGroups en 1 en la sección pod securityContext, basándose en el rango MustRunAs en el PSP. La ibm-restricted-psp puede cambiar la vaina securityContext. Estos cambios son visibles como una diferencia entre el securityContext del pod en ejecución y el securityContext en la plantilla de pod del despliegue o recurso similar que crea el pod. El ibm-privileged-psp no está mutando, por lo que un pod que se ejecuta bajo él puede ejecutarse con grupos diferentes y es posible que no pueda acceder a los datos almacenados en una PVC existente.

  1. Obtenga los detalles de todos los pods y compruebe sus PSP.

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

  2. Revise la salida del mandato para los PSP que no sean ibm-privileged-psp. Si los pods utilizan un PSP diferente, debe actualizar la aplicación para utilizar ibm-privileged-psp antes de actualizar el clúster. Si no se listan otros PSP, puede continuar con la actualización.

No se recomienda 1.25 actualizar a si la salida muestra un PSP distinto al ibm-privileged-psp PSP.

Paso 2: Verifique que el enlace de rol de clúster privileged-psp-user utiliza la configuración predeterminada

Realice los pasos siguientes para verificar que el enlace de rol de clúster de privileged-psp-user utiliza la configuración predeterminada. Esto garantiza que todas las cuentas de servicio y los usuarios estén autorizados para utilizar ibm-restricted-psp a través del enlace de rol de clúster de privileged-psp-user.

La actualización a 1.25 fallará si la vinculación de roles del clúster no tiene el valor predeterminado role y subjects exactamente como se muestra en el siguiente ejemplo.

  1. Obtenga los detalles del enlace de rol de clúster de privileged-psp-user.

    kubectl get clusterrolebinding privileged-psp-user -o yaml

  2. Revise role y subjects en la salida. Si la salida es diferente a la del ejemplo siguiente, no actualice a 1.25. Si el enlace de rol de clúster de privileged-psp-user coincide con el ejemplo siguiente, puede continuar con la actualización.

    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

Paso 3: Verificar que el enlace de rol de clúster restricted-psp-user utiliza la configuración predeterminada

Realice los pasos siguientes para verificar que el enlace de rol de clúster de restricted-psp-user utiliza la configuración predeterminada. Esto garantiza que todas las cuentas de servicio y los usuarios estén autorizados para utilizar ibm-restricted-psp a través del enlace de rol de clúster de restricted-psp-user.

La actualización a 1.25 fallará si la vinculación de roles del clúster no incluye los valores predeterminados role y subjects como se muestra en el siguiente ejemplo.

  1. Obtener los detalles del enlace de rol de clúster de restricted-psp-user

    kubectl get clusterrolebinding restricted-psp-user -o yaml

  2. Revise la salida del mandato. No actualice el clúster a la versión 1.25 si el enlace de rol de clúster no incluye los valores predeterminados para role y subjects tal como se muestra en el ejemplo siguiente.

    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

Paso 4: Comprobación de PSP que no son deIBM

Complete los pasos para comprobar si el clúster utiliza PSP que no son deIBM.

La actualización a la versión 1.25 falla si la salida comando comando incluye PSP adicionales a los del siguiente ejemplo. Es posible que tenga PSP adicionales de aplicaciones de terceros y que necesite actualizaciones de las aplicaciones o que trabaje con los proveedores de aplicaciones para determinar la estrategia de actualización adecuada que se debe utilizar para dichas aplicaciones.

  1. Liste las políticas de seguridad de pod.

    kubectl get podsecuritypolicies -o name

  2. Revise la salida del mandato.

    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. Actualice las apps para utilizar los PSP de IBM.

Pasos de la migración

Si determina que la configuración de seguridad de pod de clúster no cumple los requisitos previos de migración, debe seguir estos pasos de migración para actualizar el clúster.

Varios de los siguientes pasos de migración de Pod Security incluyen enlaces a secciones de la Kubernetes documentación. Tenga en cuenta que no todos los pasos incluidos en la documentación Kubernetes externa son relevantes para IBM Cloud Kubernetes Service los clústeres. Siga sólo los pasos que están enlazados directamente desde esta página. No siga la guía de migración Kubernetes externa en su totalidad, ya que algunas acciones no son adecuadas para IBM Cloud Kubernetes Service clústeres. Lea detenidamente los pasos siguientes para asegurarse de que realiza las acciones de migración correctas para el clúster.

Paso 1: Habilitar la admisión de seguridad de pod en el clúster de 1.24

Habilite la admisión de seguridad de pod en el clúster 1.24. Este mandato actualiza el maestro de clúster para utilizar la nueva configuración de admisión de seguridad de pod. Es posible que el maestro del clúster tarde unos minutos en actualizarse.

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

Paso 2: Revisar permisos de espacio de nombres

Revise los permisos de espacio de nombres en la documentación externa de Kubernetes. Si sus permisos de Kubernetes son gestionados por roles de servicio IAM, el rol de servicio Manager es necesario para crear o editar espacios de nombres y para establecer etiquetas de seguridad de pods.

Paso 3: Simplificar y estandarizar PSP

Limpie la configuración de seguridad de pod siguiendo los pasos de la documentación de Kubernetes externa. No modifique ni suprima ninguno de los siguientes PSP: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp, ibm-anyuid-hostaccess-psp y ibm-restricted-psp.

Paso 4: Actualizar los espacios de nombres en el clúster

Actualice los espacios de nombres en el clúster siguiendo los pasos de la documentación de Kubernetes externa. Estos pasos se deben realizar en cada espacio de nombres del clúster que no esté gestionado por IBM Cloud. Tenga en cuenta las excepciones incluidas en esta sección.

No elimine ni modifique las etiquetas de seguridad de Pod para los siguientes espacios de nombres gestionados por IBM Cloud: kube-system, ibm-system, ibm-operators.

En el paso 3.d. Omita PodSecurity la política de la documentación externa vinculada en este paso, no cree el PSP privilegiado sugerido. Si crea este PSP adicional, deberá eliminarlo antes de actualizar a la versión 1.25, tal y como se detalla en los requisitos de actualización. En su lugar, utilice el mandato siguiente para crear un RoleBinding en el rol de clúster de ibm-privileged-psp-user: kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole ibm-privileged-psp-user --group system:serviceaccounts:$NAMESPACE.

Paso 5: Revisar el proceso de creación del espacio de nombres

Revise la información de la documentación de Kubernetes externa para asegurarse de que el perfil de seguridad de pod se aplica a los nuevos espacios de nombres que se crean en el clúster.

Paso 6: Opcional. Inhabilitar la característica PSP en el clúster

  1. Inhabilite el controlador de admisión de PodSecurityPolicy en el clúster. Este mandato actualiza el maestro de clúster para utilizar la nueva configuración.
    ibmcloud ks cluster master pod-security policy disable --cluster <cluster>
  2. Espere unos minutos a que se complete la actualización del maestro de clúster.
  3. Suprima los PSP y los Roles, ClusterRoles, RoleBindings y ClusterRoleBindings asociados. Asegúrese de que los componentes que suprime no otorgan ningún otro permiso no relacionado que pueda necesitar en otro lugar. No suprima los siguientes PSP: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp, ibm-anyuid-hostaccess-psp y ibm-restricted-psp. No suprima los siguientes ClusterRoles y ClusterRoleBindings: privileged-psp-user y restricted-psp-user.

Si necesita volver a habilitar los PSP en su 1.24 clúster, ejecute ibmcloud ks cluster master pod-security policy enable --cluster <cluster>. Este mandato actualiza el maestro de clúster para utilizar la configuración de PSP.

Paso 7: Opcional. Actualizar el clúster

Actualiza tu clúster al menos a la versión 1.25 para utilizar la admisión de seguridad de pods. O bien, mantenga su clúster en la versión 1.24 con la admisión de seguridad de pods habilitada hasta que esté listo para actualizar.

Referencias

Revise la siguiente información antes de migrar de Políticas de seguridad de pod a Admisión de seguridad de pod. No siga la guía de migración tal cual, ya que algunas acciones no son adecuadas para los clústeres de IBM Cloud Kubernetes Service.