Migración desde las políticas de seguridad de pods (PSP) heredadas
PodSecurityPolicy
quedó en desuso en Kubernetes1.211.25
. Si utiliza PodSecurityPolicy en el clúster, debe migrar a los Kubernetesestándares de seguridad de pod integrados(PSS) o a una solución de política como código antes de actualizar el clúster a la versión *1.25
para evitar interrupciones en las cargas de trabajo. * Seleccione cualquier pregunta frecuente para obtener más información.
PodSecurityPolicy
Se trata de un cambio previo en el proyecto Kubernetes y no de Amazon EKS. PSPquedó en desuso en Kubernetes 1.21
y se eliminó en Kubernetes 1.25
. La comunidad de Kubernetes identificó graves problemas de usabilidad con PSP. Estas incluían la concesión accidental de permisos más amplios de lo previsto y la dificultad de inspeccionar los que PSPs se aplican en una situación determinada. Estos problemas no podían abordarse sin realizar cambios importantes. Esta es la razón principal por la que la comunidad de Kubernetes decidió eliminar PSP
Para comprobar si está utilizando PSPs en su clúster, puede ejecutar el siguiente comando:
kubectl get psp
Para ver los Pods que los PSPs impactan en el clúster, ejecute el siguiente comando. Este comando genera el nombre del Pod, el espacio de nombres y los PSPs:
kubectl get pod -A -o jsonpath='{range.items[?(@.metadata.annotations.kubernetes\.io/psp)]}{.metadata.name}{"\t"}{.metadata.namespace}{"\t"}{.metadata.annotations.kubernetes\.io/psp}{"\n"}'
Antes de actualizar el clúster a 1.25
, debe migrar PSPs a una de estas alternativas:
-
Kubernetes PSS.
-
Soluciones de políticas como código del entorno de Kubernetes.
En respuesta a la obsolescencia de PSP y a la necesidad continua de controlar la seguridad de los Pod desde el principio, la comunidad de Kubernetes creó una solución integrada con los (PSS)
Puede revisar las prácticas recomendadas para migrar PSPs a la PSS integrada en la Guía de mejores prácticas de EKS
Las soluciones de políticas como código proporcionan barreras de protección para guiar a los usuarios del clúster y evitan los comportamientos no deseados mediante controles automatizados prescritos. Las soluciones de política como código suelen utilizar los controladores de admisión dinámica de Kubernetes
Hay varias soluciones de políticas como código de código abierto disponibles para Kubernetes. Para revisar las prácticas recomendadas para migrar PSPs a una solución de política como código, consulte la sección Política como código
Los clústeres de Amazon EKS con la versión 1.13
y posterior de Kubernetes tienen una PSP predeterminada denominada eks.privileged
. Esta política se creó en 1.24
y en clústeres anteriores. No se usa en 1.25
ni en clústeres posteriores. Amazon EKS migra automáticamente esta PSP a un sistema de cumplimiento basado en PSS. No tiene que hacer nada.
No. Además de eks.privileged
, que es un PSP creado por Amazon EKS, no se realizan cambios en otros PSPs del clúster cuando se actualiza a 1.25
.
No. Amazon EKS no impedirá que el clúster se actualice a la versión 1.25
si aún no ha realizado la migración de PSP.
Cuando un clúster que contiene una PSP se actualiza a Kubernetes versión 1.25
, el servidor de API no reconoce recurso de PSP en 1.25
. Esto podría provocar que los Pods obtengan alcances de seguridad incorrectos. Para obtener una lista completa de las implicaciones, consulte Migrar de PodSecurityPolicy al controlador de admisión de PodSecurity integrado
No esperamos ningún impacto específico en las cargas de trabajo de Windows. PodSecurityContext tiene un campo llamado windowsOptions
en la API de PodSpec v1
para los Pods de Windows. Esto usa PSS en Kubernetes 1.25
. Para obtener más información y las prácticas recomendadas sobre la aplicación de PSS para las cargas de trabajo de Windows, consulte la Guía de prácticas recomendadas de EKS