Preguntas frecuentes sobre la eliminación (PSP) de políticas de seguridad de pods - Amazon EKS

Ayude a mejorar esta página

¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.

Preguntas frecuentes sobre la eliminación (PSP) de políticas de seguridad de pods

PodSecurityPolicy quedó en desuso en Kubernetes1.21 y se ha eliminado en Kubernetes1.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 es un controlador de admisión integrado que permite al administrador del clúster controlar los aspectos sensibles a la seguridad de la especificación del Pod. Si un Pod cumple con los requisitos de su PSP, el Pod se admite en el clúster como de costumbre. Si un Pod no cumple con los requisitos del PSP, el Pod se rechaza y no se puede ejecutar.

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 solucionarse 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) y la admisión de seguridad del pod (PSA). El webhook de PSA implementa los controles que se definen en la PSS.

Puede revisar las prácticas recomendadas para migrar PSPs a la PSS integrada en la Guía de mejores prácticas de EKS. También le recomendamos que consulte nuestro blog sobre la implementación de estándares de seguridad de pods en Amazon EKS. Las referencias adicionales incluyen migrar de PodSecurityPolicy al controlador de admisión PodSecurity integrado y asignar PodSecurityPolicies a los estándares de seguridad de pods.

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 para interceptar el flujo de solicitudes del servidor de API de Kubernetes mediante una llamada de webhook. Las soluciones de políticas como código mutan y validan las cargas de las solicitudes en función de las políticas escritas y almacenadas como código.

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 de la página de seguridad de pods en GitHub.

Los clústeres de Amazon EKS con la versión 1.13 o posterior de Kubernetes tienen un PSP predeterminado denominado 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 un PSP se actualiza a Kubernetes versión 1.25, el servidor de API no reconoce el 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 y la documentación de Kubernetes.