Migrar de PodSecurityPolicy al controlador de admisión PodSecurity

Autopilot Standard

En esta página se explica cómo seguir aplicando muchos controles de seguridad a nivel de pod en tus clústeres de Google Kubernetes Engine (GKE) migrando de PodSecurityPolicy al controlador de admisión PodSecurity.

Información general

PodSecurityPolicy era un controlador de admisión de Kubernetes que te permitía aplicar controles de seguridad a nivel de pod, como los estándares de seguridad de pods de Kubernetes, lo que proporcionaba un control granular sobre la configuración de seguridad de tus cargas de trabajo implementadas. El proyecto de Kubernetes ha discontinuado PodSecurityPolicy y ha eliminado la función por completo en Kubernetes v1.25.

Si actualmente usas PodSecurityPolicy en tus clústeres de GKE, inhabilita la función antes de actualizar a la versión 1.25 de GKE o a una posterior.

Para obtener más información sobre la discontinuación y la eliminación de PodSecurityPolicy, consulta el artículo Discontinuación 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 a tus cargas de trabajo desplegadas. PodSecurity te permite seguir implementando configuraciones de seguridad recomendadas a nivel de pod en tus clústeres después de migrar de PodSecurityPolicy. A diferencia de PodSecurityPolicy, PodSecurity no admite configuraciones personalizadas.

Requisitos y limitaciones

• PodSecurity está disponible en versión beta en GKE 1.23 y 1.24, y en versión estable en GKE 1.25 y versiones posteriores.
• PodSecurity no finaliza los pods que ya se están ejecutando en tus nodos, aunque infrinjan la política aplicada.
• PodSecurity no modifica los campos. Si usas algún campo mutable en tu PodSecurityPolicy, modifica la especificación de tu pod para asegurarte de que esos campos estén presentes cuando implementes las cargas de trabajo.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
  Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

• Asegúrate de tener un clúster de GKE Autopilot o Standard con la versión 1.23 o una posterior.
  • En el caso de los clústeres de Autopilot, regístrate en un canal de lanzamiento en el que la versión predeterminada sea la 1.23 o una posterior.
  • En el caso de los clústeres estándar, regístrate en un canal de lanzamiento o actualiza el clúster a una versión específica.
• Consulta tus recursos de PodSecurityPolicy para ver las configuraciones de campos mutables. Añade esos campos a tus manifiestos de pods para que las cargas de trabajo que ya se estén ejecutando en tus nodos se ajusten a una política definida en los estándares de seguridad de pods. Para obtener instrucciones, consulta el artículo Simplificar y estandarizar las políticas de seguridad de pods.

Configurar el controlador de admisión PodSecurity en un clúster

El controlador de admisión PodSecurity aplica los estándares de seguridad de pods a nivel de espacio de nombres. Debes configurar el controlador para que aplique una de las políticas definidas por los estándares de seguridad de pods en cada espacio de nombres. Están disponibles las siguientes políticas:

• Restringido: es la política más restrictiva. Cumple las prácticas recomendadas de protección de pods.
• Baseline: política mínimamente restrictiva que evita las escaladas de privilegios conocidas. Permite todos los valores predeterminados de los campos de las especificaciones de Pod.
• Privilegiada: política sin restricciones que permite cualquier acción, incluidas las escaladas de privilegios conocidas. Aplica esta política con precaución.

Para migrar la 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 secciones que aparecen a continuación.

1. Aplica la política Restricted en modo dry-run al espacio de nombres y comprueba si hay infracciones.
2. Si tus pods infringen la política Restricted, aplica la política Baseline, que es menos restrictiva, en modo dry-run al espacio de nombres y comprueba si hay infracciones.
3. Si tus pods infringen la política de referencia, modifica las especificaciones de los pods para corregir las infracciones.
4. Cuando la política Baseline ya no devuelva infracciones, aplica la política en modo enforce al espacio de nombres.

Para evitar posibles tiempos de inactividad si PodSecurity rechaza nuevos pods, sigue estos pasos en un entorno de staging. También puedes aplicar la política identificada en modo audit en lugar de en modo enforce y revisar tus registros de auditoría para encontrar los pods que se hayan rechazado.

El modo audit no aplica la política. GKE implementa los pods y añade entradas a los registros de auditoría de GKE.

Listar todos los espacios de nombres de tu clúster

Obtener una lista de todos los espacios de nombres de tu clúster. Repite los pasos de las siguientes secciones con cada espacio de nombres de la lista:

kubectl get ns

En las siguientes versiones de GKE, GKE ignora las políticas que apliques 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, no apliques políticas en kube-system.

Aplicar cada política de los estándares de seguridad de pods en modo de prueba

En los pasos siguientes, aplicará cada política en el modo dry-run, empezando por la política Restringida, que es la más restrictiva. Si el resultado muestra una advertencia, modifica la especificación del pod infractor para cumplir la política o prueba la política de referencia, que es menos restrictiva. Si el resultado no muestra ninguna advertencia, puede aplicar la política Baseline sin el modo dry-run.

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

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

   Si un pod del espacio de nombres infringe la política Restricted, el resultado será 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 tus pods para corregir la infracción y vuelve a probar el comando. También puedes probar la política Baseline, que es menos restrictiva, en el siguiente paso.

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

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

   Si un pod del espacio de nombres infringe la política de referencia, el resultado será 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 de referencia, modifícalos para corregir las infracciones y repite este paso hasta que GKE deje de mostrar una advertencia.

Precaución: También puedes usar la política Privilegiado, que no tiene restricciones. Antes de usar la política Privileged, asegúrate de que confías en todas las cargas de trabajo y los usuarios que tienen acceso al espacio de nombres. La política Privilegiado permite las elevaciones de privilegios conocidas, pero puede ser necesaria para determinadas cargas de trabajo del sistema privilegiadas.

Aplicar la política en un espacio de nombres

Cuando identifiques la política que funciona en un espacio de nombres, aplícala al espacio de nombres en modo enforce:

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

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

Repita los pasos anteriores con cada espacio de nombres de su clúster.

Inhabilitar la función PodSecurityPolicy en el clúster

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

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

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

Nota: Después de inhabilitar la función, no es necesario que elimines manualmente los objetos PodSecurityPolicy que queden. 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 elimina automáticamente todos los objetos PodSecurityPolicy restantes, incluidos los que hayan añadido GKE, Policy Controller y cualquier objeto PodSecurityPolicy que hayas definido anteriormente.

Recomendaciones

• Intenta cumplir la política de contenido no permitido siempre que sea posible. Audita tus aplicaciones para ver si se puede reforzar aún más la configuración.
• Para bloquear el modo de seguridad de los pods en una versión secundaria específica de Kubernetes, añade la etiqueta pod-security.kubernetes.io/MODE-version: VERSION a los comandos kubectl label de los pasos anteriores. Sustituye 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 comprobar si hay interrupciones o lagunas en la configuración de seguridad.
• Después de configurar PodSecurity, actualiza el proceso de creación de espacios de nombres para aplicar automáticamente una etiqueta PodSecurity a todos los espacios de nombres nuevos. Para obtener información, consulta Revisar el proceso de creación de espacios de nombres.

Siguientes pasos

• Más información sobre los estándares de seguridad de pods
• Consulta más información sobre el PodSecurity controlador de admisión.
• Consulta cómo aplicar políticas de seguridad personalizadas a nivel de pod mediante Gatekeeper.
• Consulta información sobre la discontinuación de PodSecurityPolicy.