Endurecer la seguridad del clúster

En esta página se explica cómo implementar las prácticas recomendadas actuales para reforzar la seguridad de tu clúster de Google Kubernetes Engine (GKE). En esta guía se priorizan las mitigaciones de seguridad de gran valor que requieren que el cliente tome medidas durante la creación del clúster. Las funciones menos importantes, los ajustes de seguridad predeterminados y las que se pueden habilitar después de la creación se mencionan más adelante en el documento.

Este documento está dirigido a especialistas en seguridad que definen, gestionan e implementan políticas y procedimientos para proteger los datos de una organización frente a accesos no autorizados. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

Antes de leer esta página, asegúrese de que conoce los siguientes conceptos:

Si creas clústeres en GKE, muchas de estas protecciones están habilitadas de forma predeterminada. Si vas a actualizar clústeres, asegúrate de revisar periódicamente esta guía de protección y de habilitar las nuevas funciones.

Los clústeres creados en el modo Autopilot implementan muchas funciones de protección de GKE de forma predeterminada.

Muchas de estas recomendaciones, así como otros errores de configuración habituales, se pueden comprobar automáticamente con Security Health Analytics.

Actualiza tu infraestructura de GKE periódicamente

Recomendación de CIS GKE Benchmark: 6.5.3. Asegúrate de que la actualización automática de nodos esté habilitada en los nodos de GKE

Mantener actualizada la versión de Kubernetes es una de las cosas más sencillas que puedes hacer para mejorar tu seguridad. Kubernetes introduce con frecuencia nuevas funciones de seguridad y proporciona parches de seguridad.

Consulta los boletines de seguridad de GKE para obtener información sobre los parches de seguridad.

En Google Kubernetes Engine, los planos de control se parchean y actualizan automáticamente. La actualización automática de nodos también actualiza automáticamente los nodos de tu clúster.

La actualización automática de nodos está habilitada de forma predeterminada en los clústeres creados con laGoogle Cloud consola desde junio del 2019 y en los clústeres creados con la API a partir del 11 de noviembre del 2019.

Si decides inhabilitar la actualización automática de nodos, te recomendamos que realices la actualización mensualmente según tu propia programación. En los clústeres más antiguos, se debe habilitar la actualización automática de nodos y seguir de cerca los boletines de seguridad de GKE para aplicar los parches críticos.

Para obtener más información, consulta Actualizar la versión de los nodos automáticamente.

Restringir el acceso a la red del plano de control y los nodos

Recomendaciones de CIS GKE Benchmark: 6.6.2. Preferir clústeres nativos de VPC, 6.6.3. Asegúrate de que la opción Redes autorizadas esté habilitada, 6.6.4. Asegúrate de que los clústeres se creen con el endpoint privado habilitado y el acceso público inhabilitado, y 6.6.5. Asegúrate de que los clústeres se creen con nodos privados

De forma predeterminada, el plano de control y los nodos del clúster de GKE tienen direcciones enrutables por Internet a las que se puede acceder desde cualquier dirección IP.

Práctica recomendada:

Limita la exposición a Internet del plano de control y los nodos de tu clúster.

Restringir el acceso al plano de control

Para restringir el acceso al plano de control del clúster de GKE, consulta Configurar el acceso al plano de control. Estas son las opciones que tiene para la protección a nivel de red:

  • Endpoint basado en DNS habilitado (opción recomendada): puedes controlar quién puede acceder al endpoint basado en DNS con Controles de Servicio de VPC. Controles de Servicio de VPC te permite definir un parámetro de seguridad para todas las APIs de Google de tu proyecto con atributos contextuales, como el origen de la red. Estos ajustes se pueden controlar de forma centralizada en un proyecto en todas las APIs de Google, lo que reduce el número de lugares en los que tendrías que configurar reglas de acceso.

  • Acceso a los endpoints basados en IP externos e internos inhabilitado: se impide todo acceso al plano de control a través de endpoints basados en IP.

  • Acceso a los endpoints basado en IP externa inhabilitado: esto impide todo acceso a Internet a ambos planos de control. Esta opción es adecuada si has configurado tu red local para conectarse aGoogle Cloud mediante Cloud Interconnect y Cloud VPN. Estas tecnologías conectan de forma eficaz la red de tu empresa con tu VPC en la nube.

  • Acceso al endpoint basado en IP externa habilitado, redes autorizadas habilitadas: esta opción proporciona acceso restringido al plano de control desde las direcciones IP de origen que definas. Es una buena opción si no tienes una infraestructura de VPN o si tienes usuarios remotos o sucursales que se conectan a través de la red pública de Internet en lugar de la VPN corporativa y Cloud Interconnect o Cloud VPN.

  • Acceso de endpoint externo habilitado y redes autorizadas inhabilitadas: esto permite que cualquier usuario de Internet establezca conexiones de red con el plano de control.

Si se usan endpoints basados en IP, recomendamos que los clústeres utilicen redes autorizadas.

De esta forma, se asegura de que se pueda acceder al plano de control de las siguientes formas:

  • Los CIDRs permitidos en las redes autorizadas.
  • Nodos de la VPC del clúster.
  • Direcciones IP reservadas por Google para la gestión de clústeres.

Restringir el acceso a nodos

Práctica recomendada:

Habilita los nodos privados en tus clústeres para evitar que los clientes externos accedan a los nodos.

Para inhabilitar el acceso directo a Internet de los nodos, especifica la opción --enable-private-nodes de la CLI de gcloud al crear el clúster.

De esta forma, se indica a GKE que aprovisione nodos con direcciones IP internas, lo que significa que no se puede acceder a los nodos directamente a través de Internet pública.

Restringir el acceso anónimo a los endpoints del clúster

Esta mejora de la seguridad ayuda a mitigar los riesgos asociados a la vinculación de roles accidental o malintencionada al limitar el acceso anónimo a los endpoints del clúster. De forma predeterminada, Kubernetes asigna el usuario system:anonymous y el grupo system:unauthenticated a las solicitudes anónimas a los endpoints del clúster. Si ese usuario o grupo tiene permisos en el clúster a través de enlaces de RBAC, podría dar a un usuario anónimo acceso no intencionado a endpoints que se pueden usar para poner en peligro la seguridad de un servicio o del propio clúster.

A menos que se restrinjan explícitamente mediante enlaces RBAC, se aceptarán las solicitudes de autenticación anónimas para todos los endpoints del clúster. En la versión 1.32.2-gke.1234000 de GKE y versiones posteriores, cuando creas o actualizas un clúster, puedes limitar el conjunto de endpoints a los que pueden acceder las solicitudes anónimas a los tres endpoints de comprobación del estado del servidor de la API de Kubernetes: /healthz, /livez y /readyz. Es necesario tener acceso anónimo a estos endpoints de comprobación del estado para verificar que un clúster funciona correctamente.

Para limitar el acceso anónimo a los endpoints de clústeres, especifica LIMITED para la marca --anonymous-authentication-config en cualquiera de los siguientes comandos de gcloud CLI:

La marca --anonymous-authentication-config toma el valor LIMITED o ENABLED. El valor predeterminado es ENABLED. Si asigna el valor LIMITED, las solicitudes anónimas se rechazan durante la autenticación, aunque las vinculaciones de RBAC permitan ese acceso. Las solicitudes rechazadas devuelven un estado HTTP 401.

Como se muestra en el siguiente ejemplo, puedes usar una restricción de política de organización para aplicar esta restricción de acceso en todos los clústeres de tu organización:

name: organizations/ORGANIZATION_ID/customConstraints/custom.gkeAnonymousAccessLimited
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    - UPDATE
    condition: "condition:resource.anonymousAuthenticationConfig.mode == "LIMITED"
    action: ALLOW
    displayName: Restrict anonymous access to cluster endpoints.
    description: All new and updated clusters must restrict anonymous access to cluster endpoints.

Sustituye ORGANIZATION_ID por el ID de tu organización, como 123456789.

No confíe únicamente en esta función para proteger su clúster. Considera medidas de seguridad adicionales, como las siguientes:

Para obtener información sobre la implementación de Kubernetes subyacente de esta mejora, consulta Configuración del autenticador anónimo. Para obtener más información sobre las políticas de control de acceso basado en roles (RBAC), consulta las prácticas recomendadas para el RBAC de GKE.

Usar reglas de cortafuegos con el principio de privilegio mínimo

Minimiza el riesgo de que se produzcan accesos no intencionados aplicando el principio de mínimos privilegios a las reglas de cortafuegos

GKE crea reglas de cortafuegos de VPC predeterminadas para habilitar la funcionalidad del sistema y aplicar buenas prácticas de seguridad. Para ver una lista completa de las reglas de cortafuegos creadas automáticamente, consulta Reglas de cortafuegos creadas automáticamente.

GKE crea estas reglas de cortafuegos predeterminadas con una prioridad de 1000. Si creas reglas de cortafuegos permisivas con una prioridad más alta, por ejemplo, una regla de cortafuegos allow-all para depurar, tu clúster corre el riesgo de sufrir accesos no deseados.

Usar la autenticación de grupo

Recomendación de CIS GKE Benchmark: 6.8.3. Puedes gestionar usuarios de RBAC de Kubernetes con Grupos de Google para RBAC.

Debes usar grupos para gestionar a tus usuarios. El uso de grupos permite controlar las identidades mediante tu sistema de gestión de identidades y los administradores de identidades. Si ajustas la pertenencia a un grupo, no tendrás que actualizar la configuración de RBAC cada vez que se añada o se quite a alguien del grupo.

Para gestionar los permisos de usuario con Grupos de Google, debes habilitar Grupos de Google para RBAC en tu clúster. De esta forma, puedes gestionar usuarios con los mismos permisos, mientras que los administradores de identidades pueden gestionar usuarios de forma centralizada y coherente.

Consulta las instrucciones para habilitar Grupos de Google con control de acceso basado en roles en Grupos de Google con control de acceso basado en roles.

Configurar la seguridad de los nodos de contenedor

En las siguientes secciones se describen las opciones de configuración de nodos seguros.

Habilitar los nodos de GKE blindados

Recomendación de CIS GKE Benchmark: 6.5.5. Asegúrate de que los nodos de GKE blindados estén habilitados

Los nodos de GKE blindados proporcionan una identidad y una integridad de nodos sólidas y verificables para aumentar la seguridad de los nodos de GKE, por lo que deben habilitarse en todos los clústeres de GKE.

Puedes habilitar los nodos de GKE blindados al crear o actualizar un clúster. Los nodos de GKE blindados deben habilitarse con el arranque seguro. No se debe usar el arranque seguro si necesitas módulos de kernel sin firmar de terceros. Para obtener instrucciones sobre cómo habilitar los nodos de GKE blindados y el arranque seguro con nodos de GKE blindados, consulta Usar nodos de GKE blindados.

Elegir una imagen de nodo reforzada con el tiempo de ejecución de containerd

La imagen de Container-Optimized OS con containerd (cos_containerd) es una variante de la imagen de Container-Optimized OS que tiene containerd como el entorno de ejecución del contenedor principal directamente integrado con Kubernetes.

containerd es el componente de tiempo de ejecución principal de Docker y se ha diseñado para ofrecer la funcionalidad de contenedor principal para la interfaz de tiempo de ejecución de contenedores (CRI) de Kubernetes. Es mucho menos complejo que el daemon de Docker completo y, por lo tanto, tiene una superficie de ataque más pequeña.

Para usar la imagen cos_containerd en tu clúster, consulta Imágenes de containerd.

La imagen cos_containerd es la preferida para GKE porque se ha creado, optimizado y reforzado específicamente para ejecutar contenedores.

Habilitar Workload Identity Federation para GKE

Recomendación de CIS GKE Benchmark: 6.2.2. Prioriza el uso de Google Cloud cuentas de servicio y Workload Identity

Workload Identity Federation para GKE es la forma recomendada de autenticarse en las APIs de Google Cloud .

Workload Identity Federation para GKE sustituye a Encubrimiento de metadatos y, por lo tanto, los dos métodos son incompatibles. Los metadatos sensibles protegidos por el encubrimiento de metadatos también están protegidos por Workload Identity Federation para GKE.

Endurecer el aislamiento de cargas de trabajo con GKE Sandbox

Recomendación de CIS GKE Benchmark: 6.10.4. Ten en cuenta GKE Sandbox para reforzar el aislamiento de las cargas de trabajo, sobre todo las que no sean de confianza.

GKE Sandbox proporciona una capa de seguridad adicional para evitar que el código malicioso afecte al kernel del host en los nodos del clúster.

Puedes ejecutar contenedores en un entorno sandbox para mitigar la mayoría de los ataques de escape de contenedores, también llamados ataques de escalada de privilegios local. Para ver las vulnerabilidades de escape de contenedores anteriores, consulta los boletines de seguridad. Este tipo de ataque permite que un atacante obtenga acceso a la máquina virtual host del contenedor y, por lo tanto, a otros contenedores de la misma máquina virtual. Un entorno aislado, como GKE Sandbox, puede ayudar a limitar el impacto de estos ataques.

Deberías plantearte usar un espacio aislado para una carga de trabajo en situaciones como las siguientes:

  • La carga de trabajo ejecuta código que no es de confianza
  • Quieres limitar el impacto si un atacante vulnera un contenedor de la carga de trabajo.

Consulta cómo usar GKE Sandbox en el artículo Endurecer el aislamiento de cargas de trabajo con GKE Sandbox.

Habilitar las notificaciones de boletines de seguridad

Cuando hay disponibles boletines de seguridad relevantes para tu clúster, GKE publica notificaciones sobre esos eventos como mensajes en temas de Pub/Sub que configures. Puedes recibirlas en una suscripción de Pub/Sub, integrarte con servicios de terceros y filtrar los tipos de notificaciones que quieras recibir.

Para obtener más información sobre cómo recibir boletines de seguridad mediante notificaciones de clústeres de GKE, consulta el artículo Notificaciones de clústeres.

Inhabilitar el puerto de solo lectura de kubelet no seguro

Inhabilita el puerto de solo lectura de kubelet y cambia las cargas de trabajo que usen el puerto 10255 para que usen el puerto 10250, que es más seguro.

El proceso kubelet que se ejecuta en los nodos sirve una API de solo lectura mediante el puerto no seguro 10255. Kubernetes no realiza ninguna comprobación de autenticación o autorización en este puerto. El kubelet ofrece los mismos endpoints en el puerto 10250, que es más seguro y está autenticado.

Para obtener instrucciones, consulta Inhabilitar el puerto de solo lectura de kubelet en clústeres de GKE.

Conceder permisos de acceso

En las siguientes secciones se describe cómo conceder acceso a tu infraestructura de GKE.

Usar cuentas de servicio de IAM con los mínimos privilegios

Recomendación de CIS GKE Benchmark: 6.2.1. No ejecutes clústeres de GKE con la cuenta de servicio predeterminada de Compute Engine

GKE usa cuentas de servicio de gestión de identidades y accesos que están asociadas a tus nodos para ejecutar tareas del sistema, como el registro y la monitorización. Como mínimo, estas cuentas de servicio de nodo deben tener el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine (roles/container.defaultNodeServiceAccount) en tu proyecto. De forma predeterminada, GKE usa la cuenta de servicio predeterminada de Compute Engine, que se crea automáticamente en tu proyecto, como cuenta de servicio del nodo.

Si usas la cuenta de servicio predeterminada de Compute Engine para otras funciones de tu proyecto u organización, es posible que la cuenta de servicio tenga más permisos de los que necesita GKE, lo que podría exponerte a riesgos de seguridad.

La cuenta de servicio adjunta a tus nodos solo debe usarse en cargas de trabajo del sistema que realicen tareas como el registro y la monitorización. Para tus propias cargas de trabajo, aprovisiona identidades mediante Workload Identity Federation para GKE.

Para crear una cuenta de servicio personalizada y asignarle el rol necesario para GKE, sigue estos pasos:

Consola

  1. Habilita la API de Cloud Resource Manager:

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  2. Ve a la página Cuentas de servicio:

    Ir a Cuentas de servicio

  3. Haz clic en Crear cuenta de servicio.
  4. Escribe un nombre para la cuenta de servicio. El campo ID de cuenta de servicio genera automáticamente un ID único para la cuenta de servicio en función del nombre.
  5. Haz clic en Crear y continuar.
  6. En el menú Seleccionar un rol, elige el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine.
  7. Haz clic en Listo.

gcloud

  1. Habilita la API de Cloud Resource Manager: 
    gcloud services enable cloudresourcemanager.googleapis.com
  2. Crea la cuenta de servicio: 
    gcloud iam service-accounts create SA_NAME

    Sustituye SA_NAME por un nombre único que identifique la cuenta de servicio.

  3. Asigna el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine (roles/container.defaultNodeServiceAccount) a la cuenta de servicio: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role=roles/container.defaultNodeServiceAccount

    Haz los cambios siguientes:

    • PROJECT_ID: tu ID de proyecto Google Cloud .
    • SA_NAME: el nombre de la cuenta de servicio que has creado.

Terraform

Crea una cuenta de servicio de IAM y concédele el rol roles/container.defaultNodeServiceAccount en el proyecto:

resource "google_service_account" "default" {
  account_id   = "gke-node-service-account"
  display_name = "GKE node service account"
}

data "google_project" "project" {
}

resource "google_project_iam_member" "default" {
  project = data.google_project.project.project_id
  role    = "roles/container.defaultNodeServiceAccount"
  member  = "serviceAccount:${google_service_account.default.email}"
}

Config Connector

Nota: Para este paso se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en tu clúster.

  1. Para crear la cuenta de servicio, descarga el siguiente recurso como service-account.yaml: 
    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [SA_NAME]
spec:
  displayName: [DISPLAY_NAME]

    Haz los cambios siguientes:

    • [SA_NAME]: el nombre de la nueva cuenta de servicio.
    • [DISPLAY_NAME]: un nombre visible para la cuenta de servicio.
  2. Crea la cuenta de servicio: 
    kubectl apply -f service-account.yaml
  3. Aplica el rol roles/logging.logWriter a la cuenta de servicio:
    1. Descarga el siguiente recurso en formato policy-logging.yaml. 
      apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-logging
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/logging.logWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

      Haz los cambios siguientes:

      • [SA_NAME]: el nombre de la cuenta de servicio.
      • [PROJECT_ID]: tu ID de proyecto Google Cloud .
    2. Aplica el rol a la cuenta de servicio: 
      kubectl apply -f policy-logging.yaml
  4. Aplica el rol roles/monitoring.metricWriter a la cuenta de servicio:
    1. Descarga el siguiente recurso en formato policy-metrics-writer.yaml. Sustituye [SA_NAME] y [PROJECT_ID] por tu información. 
      apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.metricWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

      Haz los cambios siguientes:

      • [SA_NAME]: el nombre de la cuenta de servicio.
      • [PROJECT_ID]: tu ID de proyecto Google Cloud .
    2. Aplica el rol a la cuenta de servicio: 
      kubectl apply -f policy-metrics-writer.yaml
  5. Aplica el rol roles/monitoring.viewer a la cuenta de servicio:
    1. Descarga el siguiente recurso en formato policy-monitoring.yaml. 
      apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-monitoring
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.viewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

      Haz los cambios siguientes:

      • [SA_NAME]: el nombre de la cuenta de servicio.
      • [PROJECT_ID]: tu ID de proyecto Google Cloud .
    2. Aplica el rol a la cuenta de servicio: 
      kubectl apply -f policy-monitoring.yaml
  6. Aplica el rol roles/autoscaling.metricsWriter a la cuenta de servicio:
    1. Descarga el siguiente recurso en formato policy-autoscaling-metrics-writer.yaml. 
      apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-autoscaling-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/autoscaling.metricsWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

      Haz los cambios siguientes:

      • [SA_NAME]: el nombre de la cuenta de servicio.
      • [PROJECT_ID]: tu ID de proyecto Google Cloud .
    2. Aplica el rol a la cuenta de servicio: 
      kubectl apply -f policy-autoscaling-metrics-writer.yaml

También puedes usar esta cuenta de servicio para recursos de otros proyectos. Para ver instrucciones al respecto, consulte el artículo sobre cómo habilitar la suplantación de identidad en cuentas de servicio en varios proyectos.

Conceder acceso a repositorios de imágenes privadas

Para usar imágenes privadas en Artifact Registry, asigna el rol Lector de Artifact Registry (roles/artifactregistry.reader) a la cuenta de servicio.

gcloud

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

Sustituye REPOSITORY_NAME por el nombre de tu repositorio de Artifact Registry.

Config Connector

Nota: Para este paso se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en tu clúster.

  1. Guarda el siguiente archivo de manifiesto como policy-artifact-registry-reader.yaml:

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-artifact-registry-reader
spec:
  member: serviceAccount:"SA_NAME"@"PROJECT_ID".iam.gserviceaccount.com
  role: roles/artifactregistry.reader
  resourceRef:
    apiVersion: artifactregistry.cnrm.cloud.google.com/v1beta1
    kind: ArtifactRegistryRepository
    name: "REPOSITORY_NAME"

    Haz los cambios siguientes:

    • SA_NAME: el nombre de tu cuenta de servicio de gestión de identidades y accesos.
    • PROJECT_ID: tu ID de proyecto Google Cloud .
    • REPOSITORY_NAME: el nombre de tu repositorio de Artifact Registry.

  2. Asigna el rol Lector de Artifact Registry a la cuenta de servicio:

    kubectl apply -f policy-artifact-registry-reader.yaml

Si usas imágenes privadas en Container Registry, también debes conceder acceso a ellas:

gcloud

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

El segmento que almacena tus imágenes tiene el nombre BUCKET_NAME con el siguiente formato:

  • artifacts.PROJECT_ID.appspot.com para las imágenes enviadas a un registro en el host gcr.io
  • STORAGE_REGION.artifacts.PROJECT_ID.appspot.com

Haz los cambios siguientes:

  • PROJECT_ID: el ID de proyecto de tu consola Google Cloud .
  • STORAGE_REGION: la ubicación del segmento de almacenamiento:
    • us para los registros del host us.gcr.io
    • eu para los registros del host eu.gcr.io
    • asia para los registros del host asia.gcr.io

Consulta la documentación de gcloud storage buckets add-iam-policy-binding para obtener más información sobre el comando.

Config Connector

Nota: Para este paso se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en tu clúster.

Aplica el rol storage.objectViewer a tu cuenta de servicio. Descarga el siguiente recurso en formato policy-object-viewer.yaml. Sustituye [SA_NAME] y [PROJECT_ID] por tu propia información. 

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
 
kubectl apply -f policy-object-viewer.yaml

Si quieres que otro usuario humano pueda crear clústeres o grupos de nodos con esta cuenta de servicio, debes asignarle el rol Usuario de cuenta de servicio en esta cuenta de servicio:

gcloud

gcloud iam service-accounts add-iam-policy-binding \
    SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member=user:USER \
    --role=roles/iam.serviceAccountUser

Config Connector

Nota: Para este paso se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en tu clúster.

Aplica el rol iam.serviceAccountUser a tu cuenta de servicio. Descarga el siguiente recurso en formato policy-service-account-user.yaml. Sustituye [SA_NAME] y [PROJECT_ID] por tu propia información. 

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
 
kubectl apply -f policy-service-account-user.yaml

En los clústeres estándar, ahora puedes crear un grupo de nodos con esta nueva cuenta de servicio. En el caso de los clústeres de Autopilot, debes crear un clúster con la cuenta de servicio. Para obtener instrucciones, consulta Crear un clúster de Autopilot.

  • Crea un grupo de nodos que use la nueva cuenta de servicio:

    gcloud container node-pools create NODE_POOL_NAME \
--service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
--cluster=CLUSTER_NAME

Si necesitas que tu clúster de GKE tenga acceso a otros servicios, debes usar Google Cloud Workload Identity Federation for GKE.

Restringir el acceso al descubrimiento de la API de clúster

De forma predeterminada, Kubernetes inicializa los clústeres con un conjunto permisivo de ClusterRoleBindings de descubrimiento que proporcionan un acceso amplio a la información sobre las APIs de un clúster, incluidas las de CustomResourceDefinitions.

Los usuarios deben tener en cuenta que el grupo system:authenticated incluido en los elementos "subjects" de los ClusterRoleBindings system:discovery y system:basic-user puede incluir a cualquier usuario autenticado (incluido cualquier usuario con una cuenta de Google) y no representa un nivel de seguridad significativo para los clústeres de GKE. Para obtener más información, consulta el artículo sobre cómo evitar los roles y grupos predeterminados.

Si quieres reforzar las APIs de descubrimiento de tu clúster, te recomendamos que tengas en cuenta una o varias de las siguientes opciones:

  • Habilita solo el endpoint basado en DNS para acceder al plano de control.
  • Configura redes autorizadas para restringir el acceso a intervalos de IP definidos.
  • Restringe el acceso al plano de control y habilita los nodos privados.

Si ninguna de estas opciones se adapta a tu caso de uso de GKE, debes tratar toda la información de descubrimiento de APIs (es decir, el esquema de CustomResources, las definiciones de APIService y la información de descubrimiento alojada en servidores de APIs de extensión) como información divulgada públicamente.

Usar espacios de nombres y RBAC para restringir el acceso a los recursos del clúster

Recomendación de la comparativa de CIS para GKE: 5.6.1. Crear límites administrativos entre recursos mediante espacios de nombres

Concede a los equipos el acceso con los mínimos privilegios a Kubernetes creando espacios de nombres o clústeres independientes para cada equipo y entorno. Asigna centros de costes y etiquetas adecuadas a cada espacio de nombres para rendir cuentas y hacer contracargos. Solo debes dar a los desarrolladores el nivel de acceso a su espacio de nombres que necesiten para desplegar y gestionar su aplicación, sobre todo en producción. Planifica las tareas que deben realizar tus usuarios en el clúster y define los permisos que necesitan para llevar a cabo cada tarea.

Para obtener más información sobre cómo crear espacios de nombres, consulta la documentación de Kubernetes. Para consultar las prácticas recomendadas al planificar la configuración del control de acceso basado en roles, consulta Prácticas recomendadas para el control de acceso basado en roles de GKE.

IAM y el control de acceso basado en roles (RBAC) funcionan conjuntamente, y una entidad debe tener permisos suficientes en cualquiera de los dos niveles para trabajar con los recursos de tu clúster.

Asigna los roles de gestión de identidades y accesos adecuados a grupos y usuarios de GKE para proporcionar permisos a nivel de proyecto y usa el control de acceso basado en roles (RBAC) para conceder permisos a nivel de clúster y de espacio de nombres. Para obtener más información, consulta Control de acceso.

Puedes usar los permisos de IAM y RBAC junto con los espacios de nombres para restringir las interacciones de los usuarios con los recursos del clúster en la Google Cloud consola. Para obtener más información, consulta Habilitar el acceso y ver los recursos del clúster por espacio de nombres.

Restringir el tráfico entre pods con una política de red

Recomendación de CIS GKE Benchmark: 6.6.7. Asegúrate de que la política de red esté habilitada y configurada correctamente

De forma predeterminada, todos los pods de un clúster pueden comunicarse entre sí. Debes controlar la comunicación entre pods según las necesidades de tus cargas de trabajo.

Restringir el acceso a la red de los servicios dificulta mucho que los atacantes se muevan lateralmente en tu clúster. Además, ofrece a los servicios cierta protección contra denegaciones de servicio accidentales o deliberadas. Dos formas recomendadas de controlar el tráfico son:

  1. Usa Istio. Consulta Instalar Istio en Google Kubernetes Engine si te interesa el balanceo de carga, la autorización de servicios, la limitación, la cuota, las métricas y más.
  2. Usa políticas de red de Kubernetes. Consulta Crear una política de red de clúster. Elige esta opción si buscas la funcionalidad básica de control de acceso que ofrece Kubernetes. Para implementar enfoques habituales para restringir el tráfico mediante políticas de red, sigue la guía de implementación de los planos técnicos de seguridad empresarial de GKE. Además, la documentación de Kubernetes incluye una guía excelente para un despliegue sencillo de nginx. Te recomendamos que uses el registro de políticas de red para verificar que tus políticas de red funcionan correctamente.

Istio y la política de red se pueden usar juntos si es necesario.

Protege tus datos con la gestión de secretos

Recomendación de CIS GKE Benchmark: 6.3.1. Considera la posibilidad de encriptar los secretos de Kubernetes con claves gestionadas en Cloud KMS.

Usa una herramienta de gestión de secretos externa para almacenar datos sensibles fuera de tu clúster y accede a esos datos mediante programación.

En Kubernetes, puedes almacenar datos sensibles en objetos Secret de tu clúster. Los secretos te permiten proporcionar datos confidenciales a las aplicaciones sin incluir esos datos en el código de la aplicación. Sin embargo, almacenar estos datos en tu clúster conlleva riesgos como los siguientes:

  • Cualquier usuario que pueda crear pods en un espacio de nombres puede leer los datos de cualquier secreto de ese espacio de nombres.
  • Cualquier persona con acceso RBAC o IAM para leer todos los objetos de la API de Kubernetes puede leer los secretos.

Cuando sea posible, utiliza un servicio de gestión de secretos externo, como Secret Manager, para almacenar tus datos sensibles fuera del clúster. Crea secretos en tu clúster solo cuando no puedas proporcionar esos datos a tus cargas de trabajo de ninguna otra forma. Te recomendamos los siguientes métodos, por orden de preferencia, para acceder a tus secretos:

  • Bibliotecas de cliente de Secret Manager: accede a los secretos de forma programática desde el código de tu aplicación mediante la API Secret Manager con la federación de identidades de carga de trabajo para GKE. Para obtener más información, consulta el artículo Acceder a secretos almacenados fuera de clústeres de GKE mediante bibliotecas de cliente.
  • Datos de Secret Manager como volúmenes montados: proporciona datos sensibles a tus pods como volúmenes montados mediante el complemento Secret Manager para GKE. Este método es útil si no puedes modificar el código de tu aplicación para usar las bibliotecas de cliente de Secret Manager. Para obtener más información, consulta el artículo sobre cómo usar el complemento Secret Manager con Google Kubernetes Engine.

  • Herramientas de gestión de secretos de terceros: herramientas de terceros como HashiCorp Vault proporcionan funciones de gestión de secretos para cargas de trabajo de Kubernetes. Estas herramientas requieren más configuración inicial que Secret Manager, pero son una opción más segura que crear secretos en el clúster. Para configurar una herramienta de terceros para la gestión de secretos, consulta la documentación del proveedor. Además, ten en cuenta las siguientes recomendaciones:

    • Si la herramienta de terceros se ejecuta en un clúster, usa un clúster diferente al que ejecuta tus cargas de trabajo.
    • Usa Cloud Storage o Spanner para almacenar los datos de la herramienta.
    • Usa un balanceador de carga de red de transferencia interno para exponer la herramienta de gestión de secretos de terceros a los pods que se ejecutan en tu red de VPC.

  • Usar secretos de Kubernetes (no recomendado): si ninguna de las opciones anteriores se adapta a tu caso práctico, puedes almacenar los datos como secretos de Kubernetes. Google Cloud cifra los datos en la capa de almacenamiento de forma predeterminada. Este cifrado predeterminado de la capa de almacenamiento incluye la base de datos que almacena el estado de tu clúster, que se basa en etcd o Spanner. Además, puedes encriptar estos secretos en la capa de aplicación con una clave que gestiones. Para obtener más información, consulta Encriptar secretos en la capa de aplicación.

Usar controladores de admisión para aplicar políticas

Los controladores de admisión son complementos que rigen y aplican la forma en que se usa el clúster. Deben estar habilitadas para usar algunas de las funciones de seguridad más avanzadas de Kubernetes y son una parte importante de la estrategia de defensa en profundidad para reforzar la seguridad de tu clúster.

De forma predeterminada, los pods de Kubernetes pueden funcionar con capacidades que van más allá de lo que necesitan. Debes limitar las funciones del pod a las que sean necesarias para esa carga de trabajo.

Kubernetes admite numerosos controles para restringir la ejecución de tus pods solo con las funciones que se hayan concedido explícitamente. Por ejemplo, Policy Controller está disponible para los clústeres de flotas. Kubernetes también tiene el controlador de admisión PodSecurity integrado, que te permite aplicar los estándares de seguridad de pods en clústeres concretos.

Policy Controller es una función de GKE Enterprise que te permite aplicar y validar la seguridad en clústeres de GKE a gran escala mediante políticas declarativas. Para saber cómo usar Policy Controller para aplicar controles declarativos en tu clúster de GKE, consulta el artículo Instalar Policy Controller.

El controlador de admisión PodSecurity te permite aplicar políticas predefinidas en espacios de nombres específicos o en todo el clúster. Estas políticas se corresponden con los diferentes estándares de seguridad de pods.

Restringir la capacidad de las cargas de trabajo para modificarse a sí mismas

Algunas cargas de trabajo de Kubernetes, especialmente las del sistema, tienen permiso para modificarse a sí mismas. Por ejemplo, algunas cargas de trabajo se escalan verticalmente de forma automática. Aunque es una opción cómoda, puede permitir que un atacante que ya haya vulnerado un nodo siga escalando en el clúster. Por ejemplo, un atacante podría hacer que una carga de trabajo de un nodo se ejecute como una cuenta de servicio con más privilegios que exista en el mismo espacio de nombres.

Lo ideal es que no se conceda a las cargas de trabajo el permiso para modificarse a sí mismas. Cuando sea necesario modificar el sistema, puedes limitar los permisos aplicando restricciones de Gatekeeper o Policy Controller, como NoUpdateServiceAccount de la biblioteca de código abierto de Gatekeeper, que proporciona varias políticas de seguridad útiles.

Cuando implementas políticas, suele ser necesario permitir que los controladores que gestionan el ciclo de vida del clúster omitan las políticas. Esto es necesario para que los controladores puedan hacer cambios en el clúster, como aplicar actualizaciones del clúster. Por ejemplo, si implementas la política NoUpdateServiceAccount en GKE, debes definir los siguientes parámetros en Constraint:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Restringir el uso del tipo de volumen gcePersistentDisk obsoleto

El tipo de volumen gcePersistentDisk, que está obsoleto, te permite montar un disco persistente de Compute Engine en pods. Te recomendamos que restrinjas el uso del tipo de volumen gcePersistentDisk en tus cargas de trabajo. GKE no realiza ninguna comprobación de autorización de gestión de identidades y accesos en el pod al montar este tipo de volumen, aunque Google Cloud realiza comprobaciones de autorización al adjuntar el disco a la VM subyacente. Por lo tanto, un atacante que ya tenga la capacidad de crear pods en un espacio de nombres puede acceder al contenido de los discos persistentes de Compute Engine de tu Google Cloud proyecto.

Para acceder a los discos persistentes de Compute Engine y usarlos, utiliza PersistentVolumes y PersistentVolumeClaims. Aplica políticas de seguridad en tu clúster que impidan el uso del tipo de volumen gcePersistentDisk.

Para evitar que se use el tipo de volumen gcePersistentDisk, aplica la política Baseline o Restricted con el controlador de admisión PodSecurity. También puedes definir una restricción personalizada en Policy Controller o en el controlador de admisión Gatekeeper.

Para definir una restricción personalizada que limite este tipo de volumen, haz lo siguiente:

  1. Instala un controlador de admisión basado en políticas, como Policy Controller o Gatekeeper OPA.

    Policy Controller

    Instala Policy Controller en tu clúster.

    Policy Controller es una función de pago para los usuarios de GKE. Policy Controller se basa en Gatekeeper, que es de código abierto, pero también te ofrece acceso a la biblioteca completa de plantillas de restricciones, a los paquetes de políticas y a la integración con los paneles de control de la consola Google Cloud para ayudarte a monitorizar y mantener tus clústeres. Los paquetes de políticas son prácticas recomendadas que puedes aplicar a tus clústeres, incluidos los paquetes basados en recomendaciones como CIS Kubernetes Benchmark.

    Gatekeeper

    Instala Gatekeeper en tu clúster.

    En los clústeres de Autopilot, abre el gatekeeper.yaml manifiesto de Gatekeeper en un editor de texto. Modifica el campo rules de la especificación MutatingWebhookConfiguration para sustituir los caracteres comodín (*) por grupos de APIs y nombres de recursos específicos, como en el siguiente ejemplo:

    apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
...
webhooks:
- admissionReviewVersions:
  - v1
  - v1beta1
  ...
  rules:
  - apiGroups:
    - core
    - batch
    - apps
    apiVersions:
    - '*'
    operations:
    - CREATE
    - UPDATE
    resources:
    - Pod
    - Deployment
    - Job
    - Volume
    - Container
    - StatefulSet
    - StorageClass
    - Secret
    - ConfigMap
  sideEffects: None
  timeoutSeconds: 1

    Aplica el manifiesto gatekeeper.yaml actualizado a tu clúster Autopilot para instalar Gatekeeper. Esto es obligatorio porque, como medida de seguridad integrada, Autopilot no permite caracteres comodín en los webhooks de admisión mutantes.

  2. Implementa la plantilla de restricción de tipos de volumen de la política de seguridad de pods integrada:

    kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml

  3. Guarda la siguiente restricción con una lista de tipos de volumen permitidos como constraint.yaml:

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: k8sPSPVolumeTypes
metadata:
  name: nogcepersistentdisk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pods"]
  parameters:
    volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]

    Esta restricción limita los volúmenes a la lista del campo spec.parameters.volumes.

  4. Despliega la restricción:

    kubectl apply -f constraint.yaml

Monitorizar la configuración del clúster

Debes auditar las configuraciones de tu clúster para detectar desviaciones de los ajustes que hayas definido.

Muchas de las recomendaciones que se incluyen en esta guía de protección, así como otras configuraciones incorrectas habituales, se pueden comprobar automáticamente con Security Health Analytics.

Revisar las opciones predeterminadas seguras

En las secciones siguientes se describen las opciones que se configuran de forma segura de forma predeterminada en los clústeres nuevos. Debes verificar que los clústeres preexistentes estén configurados de forma segura.

Proteger los metadatos de los nodos

Recomendaciones de la comparativa del CIS para GKE: 6.4.1. Asegúrate de que las APIs de metadatos de instancias de Compute Engine antiguas estén inhabilitadas y 6.4.2. Asegúrate de que el servidor de metadatos de GKE esté habilitado

Los endpoints del servidor de metadatos de Compute Engine v0.1 y v1beta1 se retiraron y se cerraron el 30 de septiembre del 2020. Estos endpoints no implementaban obligatoriamente encabezados de consultas de metadatos. Para consultar el calendario de cierre, consulta el artículo Desactivación de los endpoints del servidor de metadatos v0.1 y v1beta1.

Algunos ataques prácticos contra Kubernetes se basan en el acceso al servidor de metadatos de la máquina virtual para extraer credenciales. Estos ataques se bloquean si usas la federación de identidades de cargas de trabajo para GKE o la ocultación de metadatos.

Dejar inhabilitados los métodos de autenticación de cliente antiguos

Recomendaciones de CIS GKE Benchmark: 6.8.1. Asegúrate de que la autenticación básica mediante contraseñas estáticas esté inhabilitada y 6.8.2. Asegúrate de que la autenticación mediante certificados de cliente esté inhabilitada

Hay varios métodos de autenticación en el servidor de la API de Kubernetes. En GKE, los métodos admitidos son los tokens de portador de cuentas de servicio, los tokens de OAuth y los certificados de cliente X.509. GKE gestiona la autenticación con gcloud por ti mediante el método del token de OAuth, configurando Kubernetes, obteniendo un token de acceso y manteniéndolo actualizado.

Antes de la integración de GKE con OAuth, los únicos métodos de autenticación disponibles eran un certificado X509 generado una sola vez o una contraseña estática, pero ahora no se recomiendan y deben inhabilitarse. Estos métodos presentan una superficie de ataque más amplia para la vulneración de clústeres y se han inhabilitado de forma predeterminada desde la versión 1.12 de GKE. Si utilizas métodos de autenticación antiguos, te recomendamos que los desactives. La autenticación con una contraseña estática está obsoleta y se ha retirado desde la versión 1.19 de GKE.

Los clústeres actuales deben migrarse a OAuth. Si un sistema externo al clúster necesita una credencial de larga duración, te recomendamos que crees una cuenta de servicio de Google o una cuenta de servicio de Kubernetes con los privilegios necesarios y que exportes la clave.

Para actualizar un clúster y quitar la contraseña estática, consulta Inhabilitar la autenticación con una contraseña estática.

Actualmente, no se puede quitar el certificado de cliente emitido previamente de un clúster, pero no tiene permisos si RBAC está habilitado y ABAC está inhabilitado.

Dejar habilitado Cloud Logging

Recomendación de CIS GKE Benchmark: 6.7.1. Asegúrate de que Stackdriver Kubernetes Logging y Monitoring estén habilitados

Para reducir la sobrecarga operativa y mantener una vista consolidada de tus registros, implementa una estrategia de registro coherente en cualquier lugar en el que se implementen tus clústeres. Los clústeres de GKE Enterprise están integrados con Cloud Logging de forma predeterminada y deben seguir configurados.

.

Todos los clústeres de GKE tienen habilitado de forma predeterminada el registro de auditoría de Kubernetes, que mantiene un registro cronológico de las llamadas que se han realizado al servidor de la API de Kubernetes. Las entradas de registro de auditoría de Kubernetes son útiles para investigar solicitudes de API sospechosas, recopilar estadísticas o crear alertas de monitorización para llamadas a la API no deseadas.

Los clústeres de GKE integran el registro de auditoría de Kubernetes con Registros de auditoría de Cloud y Cloud Logging. Los registros se pueden enrutar desde Cloud Logging a tus propios sistemas de registro.

Dejar inhabilitada la interfaz web (panel de control) de Kubernetes

Recomendación de CIS GKE Benchmark: 6.10.1. Asegúrate de que la interfaz web de Kubernetes esté inhabilitada

No debes habilitar la interfaz web de Kubernetes (panel de control) cuando se ejecute en GKE.

La interfaz web de Kubernetes (panel de control) está respaldada por una cuenta de servicio de Kubernetes con muchos privilegios. La Google Cloud consola ofrece muchas de las mismas funciones, por lo que no necesitas estos permisos.

Para inhabilitar la interfaz web de Kubernetes, sigue estos pasos:

gcloud container clusters update CLUSTER_NAME \
    --update-addons=KubernetesDashboard=DISABLED

Dejar ABAC inhabilitado

Recomendación de CIS GKE Benchmark: 6.8.4. Asegúrate de que la autorización antigua (ABAC) esté inhabilitada

Debes inhabilitar el control de acceso basado en atributos (ABAC) y, en su lugar, usar el control de acceso basado en roles (RBAC) en GKE.

De forma predeterminada, ABAC está inhabilitado en los clústeres creados con la versión 1.8 de GKE o una posterior. En Kubernetes, el RBAC se usa para conceder permisos a recursos a nivel de clúster y de espacio de nombres. El control de acceso basado en roles te permite definir roles con reglas que contienen un conjunto de permisos. El control de acceso basado en roles tiene ventajas de seguridad significativas con respecto al control de acceso basado en atributos.

Si sigues usando ABAC, primero consulta los requisitos para usar RBAC. Si has actualizado tu clúster desde una versión anterior y estás usando ABAC, debes actualizar la configuración de los controles de acceso:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-legacy-authorization

Para crear un clúster con la recomendación anterior, sigue estos pasos:

gcloud container clusters create CLUSTER_NAME \
    --no-enable-legacy-authorization

Deja habilitado el controlador de admisión DenyServiceExternalIPs.

No inhabilite el controlador de admisión DenyServiceExternalIPs.

El controlador de admisión DenyServiceExternalIPs impide que los servicios usen ExternalIPs y mitiga una vulnerabilidad de seguridad conocida.

El controlador de admisión DenyServiceExternalIPs está habilitado de forma predeterminada en los clústeres nuevos creados en las versiones 1.21 y posteriores de GKE. En los clústeres que se actualicen a las versiones 1.21 y posteriores de GKE, puedes habilitar el controlador de admisión con el siguiente comando:

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips

Siguientes pasos