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.

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 versión 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 recomendadas a nivel de Pod en tus clústeres después de migrar desde PodSecurityPolicy. A diferencia de PodSecurityPolicy, PodSecurity no admite opciones de configuración 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 algún campo de mutación en tu PodSecurityPolicy, modifica las especificaciones de tu 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.
• Revisa tus recursos PodSecurityPolicy para ver opciones de configuración de campo. Agrega esos campos a los manifiestos de tu Pod para que las cargas de trabajo que ya se ejecuten en tus nodos cumplan 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 que aplique 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 del 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 cada espacio de nombres del 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 de 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 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 todos los objetos PodSecurityPolicy restantes de forma automática, incluidos los que agregó GKE, Policy Controller y cualquier objeto PodSecurityPolicy que definiste con anterioridad.

Recomendaciones

• Intenta cumplir con la política restringida siempre que sea posible. Audita tus aplicaciones para ver si la configuración se puede endurecer aún más.
• Puedes bloquear el modo de seguridad del Pod a 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 tus 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 tu espacio 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.