Migra de PodSecurityPolicy al controlador de admisión PodSecurity.

Autopilot Estándar

---

En esta página, se muestra cómo seguir aplicando muchos controles de seguridad a nivel de Pod en los clústeres de Google Kubernetes Engine (GKE) a través de la migración de PodSecurityPolicy al controlador de admisión PodSecurity.

Importante: GKE comienza a actualizar de forma automática los clústeres que aún ejecutan de la versión 1.24 a la 1.25 después de que la 1.24 llega al final del ciclo de vida el 8 de enero de 2024. Extendimos esta fecha del 31 de octubre de 2023 para minimizar las interrupciones en el período de fin de año de fin de año y proporcionaremos parches solo para las vulnerabilidades críticas durante este período extendido. Para obtener más información sobre el ciclo de vida de la versión secundaria de GKE, consulta Control de versiones y asistencia de GKE. GKE continúa deteniendo las actualizaciones automáticas hasta el 8 de enero de 2024 para los clústeres que aún usan las APIs obsoletas eliminadas en la versión 1.25, incluidas las API beta y PodSecurityPolicy. Te recomendamos actualizar tus clústeres a la versión 1.25 lo antes posible, ya que las versiones secundarias de GKE que alcanzaron el final del ciclo de vida ya no recibirán parches de seguridad ni correcciones de errores.

Descripción general

PodSecurityPolicy era un controlador de admisión de Kubernetes que te permite aplicar controles de seguridad a nivel del Pod, como los estándares de seguridad de Pods de Kubernetes, lo que proporciona un control detallado sobre la configuración de seguridad de las cargas de trabajo implementadas. El proyecto de Kubernetes dio de baja PodSecurityPolicy y quitó la función por completo en Kubernetes v1.25.

Si al presente usas PodSecurityPolicy en tus clústeres de GKE, inhabilita la función antes de actualizar a la versión 1.25 de GKE y posteriores.

Para obtener más información de la baja y la eliminación de PodSecurityPolicy, consulta la baja de PodSecurityPolicy.

PodSecurity y PodSecurityPolicy

El controlador de admisión PodSecurity está disponible y habilitado de forma predeterminada en los clústeres que ejecutan las siguientes versiones de GKE:

• Versión 1.25 o posterior: Estable
• Versión 1.23 y 1.24: Beta

PodSecurity te permite aplicar las políticas definidas en los Estándares de seguridad de Pods en las cargas de trabajo implementadas. PodSecurity te permite seguir implementando opciones de configuración de seguridad a nivel de Pod en los clústeres después de migrar desde PodSecurityPolicy. A diferencia de PodSecurityPolicy, PodSecurity no admite configuraciones personalizadas.

Requisitos y limitaciones

• PodSecurity está disponible en versión Beta en las versiones 1.23 y 1.24 de GKE, y en la versión 1.25 y posteriores de GKE.
• PodSecurity no finaliza los Pods que ya se están ejecutando en los nodos, incluso si infringen la política aplicada.
• PodSecurity no muta los campos. Si usas campos de mutación en tu PodSecurityPolicy, modifica las especificaciones del pod para asegurarte de que esos campos estén presentes cuando implementes las cargas de trabajo.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

• Asegúrate de tener un clúster de GKE Autopilot o Standard que ejecute la versión 1.23 o posterior.
  • Para los clústeres de Autopilot, inscríbete en un canal de versiones en el que la versión predeterminada sea la 1.23 o posterior.
  • Para los clústeres estándar, inscríbete en un canal de versiones o actualiza el clúster a una versión específica.
• Verifica tus recursos de PodSecurityPolicy para cambiar las configuraciones de campo. Agrega esos campos a los manifiestos de Pods para que cualquier carga de trabajo que ya se ejecute en los nodos cumpla con una política definida en los Estándares de seguridad de Pods. Para obtener instrucciones, consulta Simplifica y estandariza las políticas de seguridad de Pods.

Configura el controlador de admisión PodSecurity en tu clúster

El controlador de admisión PodSecurity aplica los estándares de seguridad de Pods a nivel del espacio de nombres. Debes configurar el controlador para aplicar una de las políticas que definen los estándares de seguridad de pods en cada espacio de nombres. Las siguientes políticas están disponibles:

• Restringida: La política más restrictiva. Cumple con las prácticas recomendadas de endurecimiento de Pods.
• Referencia: Política lo mínimo restrictiva que evita las elevaciones de privilegios conocidas. Permite todos los valores predeterminados para los campos en las especificaciones de Pod.
• Privilegiada: Política sin restricciones que permite todo, incluidos los escalamientos de privilegios conocidos. Aplica esta política con precaución.

Para migrar tu configuración de PodSecurityPolicy al controlador de admisión PodSecurity, haz lo siguiente en todos los espacios de nombres de tu clúster. Estos pasos se describen en detalle en las siguientes secciones.

1. Aplica la política Restricted en el modo dry-run al espacio de nombres y verifica si hay incumplimientos.
2. Si tus Pods infringen la política Restricted, aplica la política Baseline menos restrictiva en el modo dry-run al espacio de nombres y verifica las infracciones.
3. Si tus Pods infringen la política Baseline, modifica las especificaciones del Pod para corregir los incumplimientos.
4. Cuando la política de Baseline ya no muestre incumplimientos, aplica la política en modo enforce al espacio de nombres.

Para evitar un posible tiempo de inactividad si PodSecurity rechaza Pods nuevos, realiza estos pasos en un entorno de etapa de pruebas. Como alternativa, puedes aplicar la política identificada en modo audit en lugar de enforce y revisar tus registros de auditoría para encontrar posibles Pods rechazados.

El modo audit no aplica la política. GKE implementa los Pods y agrega entradas a los registros de auditoría de GKE.

Obtén una lista de todos los espacios de nombres en su clúster

Obtén una lista de todos los espacios de nombres en tu clúster. Repite los pasos de las siguientes secciones para cada espacio de nombres en la lista:

kubectl get ns

En las siguientes versiones de GKE, GKE ignora las políticas que aplicas al espacio de nombres kube-system:

• 1.23.6-gke.1900 y versiones posteriores
• 1.24.0-gke.1200 y versiones posteriores

En versiones anteriores de GKE, evita aplicar políticas en kube-system.

Aplica cada política de los Estándares de seguridad de Pods en el modo de ejecución de prueba

En los siguientes pasos, aplicarás cada política en modo dry-run, comenzando con la política de Restricted más restrictiva. Si el resultado muestra una advertencia, modifica la especificación del Pod que incumple las políticas para cumplir con la política o prueba la política Baseline menos restrictiva. Si el resultado no muestra una advertencia, puedes aplicar la política Baseline sin el modo dry-run.

1. Aplica la política Restricted en el modo dry-run:

   kubectl label --dry-run=server --overwrite ns NAMESPACE \
       pod-security.kubernetes.io/enforce=restricted
   

   Si un Pod en el espacio de nombres infringe la política Restricted, el resultado es similar al siguiente:

   Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "restricted:latest"
   namespace/NAMESPACE labeled
   

   Si la política Restricted muestra una advertencia, modifica los Pods para corregir la infracción y vuelve a intentar el comando. Como alternativa, prueba la política Baseline menos restrictiva en el siguiente paso.

2. Aplica la política Referencia en modo dry-run:

   kubectl label --dry-run=server --overwrite ns NAMESPACE \
       pod-security.kubernetes.io/enforce=baseline
   

   Si un Pod en el espacio de nombres infringe la política Baseline, el resultado es similar al siguiente:

   Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "baseline:latest"
   namespace/NAMESPACE labeled
   

Si tus Pods infringen la política Baseline, modifica tus pods para corregir los incumplimientos y repetir este paso hasta que GKE ya no muestre una advertencia.

Precaución: De manera opcional, puedes usar la política Privileged, que no tiene restricciones. Antes de usar la política Privileged, asegúrate de confiar en todas las cargas de trabajo y usuarios que tienen acceso al espacio de nombres. La política Privileged permite elevaciones de privilegios conocidos, pero puede ser necesaria para ciertas cargas de trabajo del sistema privilegiadas.

Aplica la política en un espacio de nombres

Cuando identifiques la política que funciona para un espacio de nombres, aplica la política al espacio de nombres en el modo enforce:

kubectl label --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=POLICY

Reemplaza POLICY por el nombre de la política, que puede ser restricted, baseline o privileged.

Asegúrate de repetir los pasos anteriores para cada espacio de nombres en tu clúster.

Inhabilita la función PodSecurityPolicy en tu clúster

Después de configurar el controlador de admisión PodSecurity para todos los espacios de nombres en tu clúster, inhabilita la función PodSecurityPolicy:

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-pod-security-policy

Reemplaza CLUSTER_NAME por el nombre de tu clúster de GKE.

Nota: Después de inhabilitar la función, no es necesario que quites de forma manual ningún objeto PodSecurityPolicy restante. Cuando ejecutas kubectl get psp, GKE puede mostrar las políticas restantes, pero GKE no aplica esas políticas.

Cuando actualizas tu clúster a la versión 1.25 de GKE, GKE quita automáticamente todos los objetos PodSecurityPolicy restantes, incluidos los que agregó GKE, Config Management y cualquier objeto PodSecurityPolicy que definiste antes.

Recomendaciones

• Cuando sea posible, intenta cumplir con la política restringida. Audita tus aplicaciones para ver si la configuración se puede endurecer aún más.
• Puedes bloquear el modo de seguridad del pod en una versión secundaria específica de Kubernetes si agregas la etiqueta pod-security.kubernetes.io/MODE-version: VERSION a los comandos kubectl label en los pasos anteriores. Reemplaza VERSION por el número de versión de Kubernetes, como v1.24.
• Después de inhabilitar la función PodSecurityPolicy, revisa las aplicaciones en ejecución para verificar si hay interrupciones o brechas en la configuración de seguridad.
• Después de configurar PodSecurity, actualiza el proceso de creación de espacios de nombres para aplicar de forma automática una etiqueta PodSecurity a todos los espacios de nombres nuevos. Para obtener más información, consulta Revisa el proceso de creación de espacios de nombres.

Próximos pasos

• Obtén más información de los estándares de seguridad de los pods.
• Obtén más información del controlador de admisión PodSecurity.
• Obtén información acerca de cómo aplicar políticas de seguridad personalizadas a nivel de los Pods con Gatekeeper.
• Lee sobre la baja de PodSecurityPolicy.