Aplica políticas de seguridad de Autopilot en clústeres de Standard

Los clústeres de Autopilot de Google Kubernetes Engine (GKE) aplican varias políticas de seguridad diseñadas para evitar muchas rutas de ataque comunes. En este documento, se muestra a los administradores de la plataforma cómo aplicar algunas o todas estas políticas de Autopilot en clústeres estándar. No puedes inhabilitar la aplicación de políticas de clúster en los clústeres de Autopilot, ya que estos están diseñados para una postura de seguridad de GKE de referencia más alta.

En los clústeres estándar, puedes habilitar e inhabilitar políticas específicas en cualquier momento. Los administradores de la organización pueden controlar si se pueden inhabilitar políticas específicas de Autopilot aplicando una restricción personalizada en la organización, la carpeta o el proyecto. Puedes usar estas políticas predefinidas para aplicar las prácticas recomendadas de seguridad sin necesidad de escribir roles y vinculaciones de RBAC complejos. Muchas de las políticas a nivel del clúster pueden ayudarte a mejorar la seguridad del clúster, incluso si no te interesa usar el modo Autopilot para el clúster o las cargas de trabajo. Para obtener más información sobre las políticas de clúster de Autopilot disponibles, consulta la sección Políticas admitidas.

Consideraciones para aplicar las políticas de clústeres de Autopilot

Si bien los clústeres de Autopilot siempre aplican estas políticas, los clústeres de Standard suelen tener cargas de trabajo y grupos de nodos existentes que podrían incumplir las políticas que aplicas. Antes de aplicar o inhabilitar una política en tu clúster, ten en cuenta las siguientes consideraciones:

  • Los cambios se aplican solo a las cargas de trabajo nuevas: Cuando habilitas una política que se aplica a las cargas de trabajo, los cambios se aplican solo a los Pods que se crean o modifican después de que habilitas esa política. Los Pods existentes que infringen la política pueden seguir ejecutándose. Antes de habilitar una política, revisa las cargas de trabajo existentes en el clúster para verificar que cumplan con la restricción de la política.
  • Las políticas de grupos de nodos se aplican a todos los nodos: Cuando habilitas una política que se aplica a los grupos de nodos de tu clúster de Standard, las restricciones se aplican a los grupos de nodos nuevos y existentes. Si un grupo de nodos existente incumple la política, fallará la operación de actualización del clúster. Por ejemplo, si intentas habilitar la política no-standard-node-pools en un clúster que tiene un grupo de nodos existente administrado por el usuario, tu operación fallará. Antes de habilitar una política de grupo de nodos, revisa los grupos de nodos existentes en el clúster.
  • Habilitar todas las políticas habilita el modo Autopilot: Si habilitas todas las políticas de Autopilot disponibles (incluida la política que impide los grupos de nodos administrados por el usuario), todas las cargas de trabajo de tu clúster solo podrán ejecutarse en el modo Autopilot. Esto significa que todas tus cargas de trabajo deben cumplir con las restricciones de seguridad de Autopilot y con todas las políticas del clúster. Este enfoque te permite ejecutar todo el clúster Standard en modo Autopilot, con la opción de inhabilitar políticas específicas cuando sea necesario.

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 la gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se indican en este documento.

Habilita políticas específicas de Autopilot en tu clúster

Usa la gcloud CLI o la API de GKE para habilitar políticas específicas cuando crees o actualices un clúster estándar. Para agregar políticas específicas del clúster de Autopilot a la lista de políticas que GKE aplica en el clúster, usa la marca --autopilot-cluster-policies con el comando gcloud container clusters create o el comando gcloud container clusters update.

En el siguiente ejemplo, se muestra cómo habilitar políticas en un clúster existente:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --autopilot-cluster-policies=AUTOPILOT_POLICIES

Reemplaza lo siguiente:

  • CLUSTER_NAME: es el nombre de tu clúster estándar.
  • CONTROL_PLANE_LOCATION: Es la región o zona del plano de control del clúster, como us-central1 o us-central1-a.
  • AUTOPILOT_POLICIES: Es una lista separada por comas de políticas de clúster de Autopilot que se comenzarán a aplicar en el clúster, como no-system-mutation,no-system-impersonation. Debes especificar una o más políticas admitidas. Las políticas que especifiques se agregarán a la lista de políticas que GKE ya aplica en el clúster. Para inhabilitar la aplicación de una política, consulta la sección Inhabilita políticas específicas de Autopilot en tu clúster.

Si el comando falla con un mensaje de error que comienza con Bad value [invalid policy]:, verifica que todos los nombres de políticas que especificaste estén en la lista de políticas admitidas.

Verifica la aplicación de la política

Después de habilitar una política específica, puedes verificar que la aplicación funcione intentando crear un recurso que incumpla esa política. Por ejemplo, si habilitas la política no-system-mutation, puedes intentar crear un Pod en el espacio de nombres kube-system. GKE bloquea la operación de creación del Pod y muestra un mensaje de error similar al siguiente:

Error from server (Forbidden): pods is forbidden: User cannot create resource "pods" in API group "" in the namespace "kube-system": GKE Warden authz [denied by managed-namespaces-limitation]: the namespace "kube-system" is managed and the request's verb "create" is denied

Inhabilita políticas específicas de Autopilot en tu clúster

Puedes inhabilitar cualquiera de las políticas del clúster de Autopilot en cualquier momento. Inhabilitar una política es útil en situaciones en las que cambiaron tus requisitos de seguridad o cuando se interrumpió un flujo de trabajo existente al habilitar esa política. Para quitar una política de la lista de políticas que GKE aplica en el clúster, usa la marca --remove-autopilot-cluster-policies con el comando gcloud container clusters update:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --remove-autopilot-cluster-policies=AUTOPILOT_POLICIES

Debes especificar al menos un valor para la marca --remove-autopilot-cluster-policies. Si especificas esta marca sin un valor, la operación fallará.

Si el comando falla con un mensaje de error que comienza con Bad value [invalid policy]:, verifica que todos los nombres de políticas que especificaste estén en la lista de políticas admitidas.

Aplica políticas de clústeres de Autopilot en organizaciones

Los administradores de la organización pueden aplicar el uso de estas políticas de clúster en una organización, un proyecto o una carpeta con restricciones de políticas de la organización personalizadas. Esta medida adicional puede ayudarte a evitar la eliminación no autorizada o no intencional de las políticas de clúster requeridas de un clúster. Usa el campo ClusterPolicyConfig en tu restricción personalizada, como en el siguiente ejemplo:

name: organizations/ORGANIZATION_ID/customConstraints/custom.autopilotClusterPolicies
resourceTypes:
-   container.googleapis.com/Cluster
methodTypes:
-   CREATE
-   UPDATE
condition: "resource.ClusterPolicyConfig.no_system_mutation == true && resource.ClusterPolicyConfig.no_system_impersonation == true"
actionType: ALLOW
displayName: Autopilot policies in Standard clusters.
description: For all new and existing Standard clusters, enable the no_system_mutation and no_system_impersonation Autopilot cluster policies. For more information, see https://docs.cloud.google.com/kubernetes-engine/security/autopilot-cluster-policies-standard.

Políticas admitidas

Cada una de las políticas de Autopilot disponibles en los clústeres estándar implementa una o más prácticas recomendadas de seguridad a nivel del clúster. Las políticas como no-system-mutation, no-system-impersonation y no-unsafe-webhooks ayudan a mejorar la seguridad de cualquier clúster de GKE, incluso si no te interesa usar el modo Autopilot.

En la siguiente tabla, se describen las políticas de Autopilot que puedes habilitar en los clústeres estándar y se te ayuda a prepararte para la aplicación de políticas:

Nombre de la política Descripción Qué hacer antes de habilitar la función
no-system-mutation Impedir la creación o modificación de recursos en los espacios de nombres del sistema de GKE (como kube-system) Mueve tus Pods de los espacios de nombres del sistema a tus propios espacios de nombres.
no-system-impersonation Bloquea los intentos de suplantación de identidad de los usuarios del sistema y evita la creación de CertificateSigningRequests con entidades principales del sistema. Busca cualquier CertificateSigningRequest no autorizado que se haya generado para identidades del sistema. Si encuentras solicitudes de firma de certificados no autorizadas aprobadas, rota las credenciales del clúster para invalidar los certificados.
no-unsafe-webhooks Evita que las políticas y los webhooks de admisión intercepten recursos críticos del sistema, como objetos Node, PersistentVolumes o CertificateSigningRequests. Usa el servicio de Recommender para identificar los webhooks que interceptan recursos del sistema. Si encuentras algún webhook, modifica su configuración. Para obtener más información, consulta Garantiza la estabilidad del plano de control cuando usas webhooks.
no-standard-node-pools Impedir que existan en el clúster grupos de nodos administrados por el usuario, incluidos los grupos de nodos creados de forma manual y los creados automáticamente Solo pueden existir grupos de nodos de Autopilot en el clúster. Borra todos los grupos de nodos existentes que no sean de Autopilot, incluido el grupo de nodos predeterminado que se creó con el clúster.

¿Qué sigue?