Endurecer la seguridad del clúster

Debido a la gran velocidad de desarrollo en Kubernetes, a menudo hay nuevas funciones de seguridad que puedes usar. En esta página, se te guiará para que puedas implementar nuestra guía actual a fin de endurecer tu clúster de Google Kubernetes Engine (GKE).

En esta guía, se priorizan las mitigaciones de seguridad de alto valor que requieren acciones por parte del cliente durante la creación del clúster. Las funciones menos importantes, la configuración segura predeterminada y las opciones que pueden habilitarse luego del momento de la creación se mencionan más adelante en el documento. Para obtener una descripción general sobre los temas de seguridad, consulta la Descripción general de seguridad.

Muchas de estas recomendaciones, así como otras configuraciones erróneas comunes, se pueden verificar automáticamente con Estadísticas del estado de la seguridad.

Se especifica si las siguientes recomendaciones se relacionan con una Recomendación de CIS GKE Benchmark.

Actualiza la infraestructura de GKE de manera oportuna

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

Mantener la versión de Kubernetes actualizada es una de las tareas más simples que puedes realizar para mejorar tu seguridad. Kubernetes suele agregar nuevas funciones de seguridad y proporcionar parches de seguridad con frecuencia.

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

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

Si decides inhabilitar la actualización automática de nodos, te recomendamos que realices una actualización mensual según tus preferencias. Para los clústeres más antiguos, se debería habilitar la actualización automática de nodos y seguir de cerca los Boletines de seguridad de GKE en busca de los parches fundamentales.

Para obtener más información, consulta Actualización automática de nodos.

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

Recomendaciones de CIS GKE Benchmark: 6.6.2. Prefiere clústeres nativos de la VPC, 6.6.3. Asegúrate de que las redes autorizadas de la instancia principal estén habilitadas, 6.6.4. Asegúrate de que los clústeres se creen con el extremo privado habilitado y el acceso público inhabilitado, y 6.6.5. Asegúrate de que los clústeres se creen con nodos privados

Deberías limitar la exposición en Internet del plano de control y los nodos de tu clúster. Esta configuración solo se puede establecer en el momento de la creación del clúster.

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

Para el plano de control del clúster de GKE, consulta la página Configura un clúster privado. Existen tres tipos diferentes de clústeres privados que pueden ofrecer protección a nivel de red:

  • Acceso al extremo público inhabilitado: Esta es la opción más segura, ya que impide el acceso a Internet a los paneles de control y los nodos. Esta es una buena alternativa si configuraste tu red local para conectarte a Google Cloud mediante Cloud Interconnect y Cloud VPN. Esas tecnologías conectan la red de tu empresa a tu VPC en la nube de forma eficaz.
  • Acceso al extremo público habilitado, redes autorizadas habilitadas (recomendado): Esta opción proporciona acceso restringido al plano de control desde las direcciones IP de origen que definas. Esta es una buena opción si no tienes una infraestructura de VPN existente o tienes usuarios remotos o sucursales que se conectan a través de la Internet pública en lugar de la VPN corporativa, Cloud Interconnect o Cloud VPN.
  • Acceso al extremo público habilitado, redes autorizadas inhabilitadas: Este es el valor predeterminado y permite que cualquier persona en Internet realice conexiones de red al plano de control.

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

Esto le indica a GKE que debe aprovisionar a los nodos con direcciones IP internas, lo que significa que no se puede acceder directamente a los nodos a través de la Internet pública.

Recomendamos que los clústeres usen al menos redes autorizadas principales y nodos privados. Esto garantiza que el plano de control sea accesible a través de las siguientes opciones:

  • Los CIDR permitidos en las redes autorizadas.
  • Los nodos dentro de la VPC de tu clúster.
  • Los trabajos de producción interna de Google que administran tu plano de control.

Esto se corresponde con las siguientes marcas de gcloud en el momento de creación del clúster:

  • --enable-ip-alias
  • --enable-private-nodes
  • --enable-master-authorized-networks

Usa reglas de firewall con privilegios mínimos

Minimiza el riesgo de acceso no deseado mediante el principio de privilegio mínimo para reglas de firewall

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

GKE crea estas reglas de firewall predeterminadas con una prioridad de 1,000. Si creas reglas de firewall permisivas con una prioridad más alta, por ejemplo, una regla de firewall allow-all para la depuración, el clúster está en riesgo de acceso no deseado.

Autenticación de grupo

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

Debes usar grupos para administrar a tus usuarios. El uso de grupos permite controlar las identidades mediante el Sistema de administración de identidad y los Administradores de identidad. El ajuste de la membresía del grupo elimina la necesidad de actualizar tu configuración de RBAC cada vez que se agrega a alguien al grupo o se lo quita.

A fin de administrar los permisos del usuario con Grupos de Google, debes habilitar los Grupos de Google para RBAC en tu clúster. Esto te permite administrar usuarios con los mismos permisos de forma sencilla, al tiempo que permite que tus administradores de identidad administren usuarios de manera centralizada y coherente.

Consulta Grupos de Google para RBAC a fin de obtener instrucciones sobre cómo habilitar Grupos de Google para RBAC.

Opciones de nodo del contenedor

En las siguientes secciones, se describen opciones de configuración de nodo seguras.

Habilitar nodos de GKE protegidos

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

Los nodos de GKE protegidos proporcionan una identidad y una integridad de nodo sólidas y verificables para aumentar la seguridad de los nodos de GKE y deberían estar habilitados en todos los clústeres de GKE.

Puedes habilitar los nodos de GKE protegidos durante la creación o actualización del clúster. Los nodos de GKE protegidos deberían habilitarse con un inicio seguro. El inicio seguro no debe usarse si necesitas módulos de kernel sin firmar de terceros. Para obtener instrucciones sobre cómo habilitar los nodos de GKE protegidos y cómo habilitar el inicio seguro con nodos de GKE protegidos, consulta Usa nodos de GKE protegidos.

Elige una imagen de nodo endurecido con el entorno 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 con containerd como el entorno de ejecución principal del contenedor integrado directamente con Kubernetes.

containerd es el componente de entorno de ejecución principal de Docker y se lo diseñó con el fin de proveer funcionalidad de contenedor principal para la interfaz de entorno de ejecución del contenedor (CRI) de Kubernetes. Es significativamente 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 imagen preferida de GKE porque se compiló, optimizó y endureció específicamente para los contenedores en ejecución.

Habilita la federación de identidades para cargas de trabajo para GKE

Recomendación de CIS GKE Benchmark: 6.2.2. Prefiere usar cuentas de servicio de Google Cloud y Workload Identity dedicadas

La federación de identidades para cargas de trabajo para GKE es la forma recomendada de autenticarse en las APIs de Google Cloud.

La federación de identidades para cargas de trabajo para GKE reemplaza la necesidad de usar ocultamiento de metadatos, por lo que los dos enfoques son incompatibles. Los metadatos sensibles protegidos con la ocultación de metadatos también están protegidos por la federación de identidades para cargas de trabajo para GKE.

Endurece el aislamiento de las cargas de trabajo con GKE Sandbox

Recomendación de CIS GKE Benchmark: 6.10.4. Considera usar GKE Sandbox a fin de endurecer el aislamiento de las cargas de trabajo, en especial para las cargas de trabajo que no sean de confianza.

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

Puedes ejecutar contenedores en un entorno de zona de pruebas para mitigar la mayoría de los ataques de escape de contenedores, también llamados ataques de elevación de privilegios locales. 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 VM host del contenedor y, por lo tanto, obtenga acceso a otros contenedores en la misma VM. Con una zona de pruebas como GKE Sandbox puedes limitar el impacto de estos ataques.

Debes considerar la zona de pruebas de una carga de trabajo en situaciones como las siguientes:

  • La carga de trabajo ejecuta código no confiable
  • Deseas limitar el impacto si un atacante compromete un contenedor en la carga de trabajo.

Obtén información sobre cómo usar GKE Sandbox en Endurece el aislamiento de las cargas de trabajo con GKE Sandbox.

Habilita las notificaciones del boletín de seguridad

Cuando hay boletines de seguridad disponibles que son relevantes para el clúster, GKE publica notificaciones sobre esos eventos como mensajes en los temas de Pub/Sub que configuras. Puedes recibir estas notificaciones en una suscripción de Pub/Sub, integrarlas a servicios de terceros y filtrar por los tipos de notificaciones que deseas recibir.

Para obtener más información sobre cómo recibir boletines de seguridad con notificaciones de clústeres de GKE, consulta Notificaciones de clúster.

Permisos

Usa las cuentas de servicio de IAM con privilegios mínimos

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

Cada nodo de GKE tiene una cuenta de servicio de administración de identidades y accesos (IAM) asociada. De forma predeterminada, a los nodos se les asigna la cuenta de servicio predeterminada de Compute Engine, que puedes encontrar si te diriges a la sección de IAM de la consola de Google Cloud. Esta cuenta posee un acceso amplio de manera predeterminada, por lo que es útil para una gran variedad de aplicaciones. Sin embargo, tiene más permisos que los necesarios para ejecutar tu clúster de Kubernetes Engine. Debes crear y usar una cuenta de servicio con privilegios mínimos para que la usen tus nodos en lugar de la cuenta de servicio predeterminada de Compute Engine.

Con el lanzamiento de la federación de identidades para cargas de trabajo para GKE, sugerimos un caso de uso más limitado para la cuenta de servicio de nodo. Esperamos que la cuenta de servicio de nodo la usen daemons del sistema responsables de registro, supervisión y tareas similares. En cambio, las cargas de trabajo en los Pods deben aprovisionarse identidades con la federación de identidades para cargas de trabajo para GKE.

GKE requiere, como mínimo, que la cuenta de servicio tenga los roles monitoring.viewer, monitoring.metricWriter, logging.logWriter, stackdriver.resourceMetadata.writer y autoscaling.metricsWriter. Obtén más información sobre los roles de supervisión y los roles de registro.

Los siguientes comandos crean una cuenta de servicio de IAM con los permisos mínimos requeridos para operar GKE: También puedes usar la cuenta de servicio para los recursos de otros proyectos. Para obtener instrucciones, consulta Habilitación de identidad temporal como cuenta de servicio entre proyectos.

gcloud

gcloud iam service-accounts create SA_NAME \
    --display-name=DISPLAY_NAME

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/logging.logWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/stackdriver.resourceMetadata.writer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/autoscaling.metricsWriter

Reemplaza lo siguiente:

  • SA_NAME: Es el nombre de la cuenta de servicio nueva.
  • DISPLAY_NAME: Es el nombre visible de la cuenta de servicio nueva, que es más fácil de identificar.
  • PROJECT_ID: El ID del proyecto en el que deseas crear la cuenta de servicio nueva.

Config Connector

Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el 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]

    Reemplaza lo siguiente:

    • SA_NAME: Es el nombre de la cuenta de servicio nueva.
    • DISPLAY_NAME: Es el nombre visible de la cuenta de servicio nueva, que es más fácil de identificar.

    Luego, ejecuta lo siguiente: 

    kubectl apply -f service-account.yaml

  2. Aplica la función logging.logWriter a la cuenta de servicio. Descarga el siguiente recurso como policy-logging.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información. 

    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]
    kubectl apply -f policy-logging.yaml

  3. Aplica la función monitoring.metricWriter. Descarga el siguiente recurso como policy-metrics-writer.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia 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]
    kubectl apply -f policy-metrics-writer.yaml

  4. Aplica la función monitoring.viewer. Descarga el siguiente recurso como policy-monitoring.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información. 

    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]
    kubectl apply -f policy-monitoring.yaml

  5. Aplica la función autoscaling.metricsWriter. Descarga el siguiente recurso como policy-autoscaling-metrics-writer.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información. 

    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]
    kubectl apply -f policy-autoscaling-metrics-writer.yaml

Otorga acceso a repositorios de imágenes privadas

Para usar imágenes privadas en Artifact Registry, otorga el rol de 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

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

Config Connector

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

  1. Guarda el siguiente 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

    Reemplaza lo siguiente:

    • SA_NAME: El nombre de tu cuenta de servicio de IAM.
    • PROJECT_ID: Es el ID de tu proyecto de Google Cloud.
    • REPOSITORY_NAME: Es el nombre de tu repositorio de Artifact Registry.

  2. Otorga el rol de lector de Artifact Registry a la cuenta de servicio:

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

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

gsutil

gsutil iam ch \
  serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com:objectViewer \
  gs://BUCKET_NAME

El depósito 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, o
  • STORAGE_REGION.artifacts.PROJECT_ID.appspot.com

Reemplaza lo siguiente:

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

Consulta la documentación de gsutil iam para obtener más información sobre el comando.

Config Connector

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

Aplica la función storage.objectViewer a tu cuenta de servicio. Descarga el siguiente recurso como policy-object-viewer.yaml. Reemplaza [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 deseas que otro usuario humano pueda crear clústeres o grupos de nodos nuevos con esta cuenta de servicio, debes otorgarle la función del 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: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

Aplica la función iam.serviceAccountUser a tu cuenta de servicio. Descarga el siguiente recurso como policy-service-account-user.yaml. Reemplaza [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

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

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

    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 de Google Cloud, debes usar la federación de identidades para cargas de trabajo para GKE.

Restringe el acceso al descubrimiento de API del clúster

De forma predeterminada, Kubernetes arranca los clústeres con un conjunto de permisos de ClusterRoleBindings de descubrimiento que dan un amplio acceso a la información sobre las API de un clúster, incluidas las de CustomResourceDefinitions.

Los usuarios deben tener en cuenta que el Grupo system:authenticated, incluido en los sujetos de los ClusterRoleBindings system:discovery y system:basic-user, puede incluir a cualquier usuario autenticado (incluso cualquier usuario con una Cuenta de Google) y no representa un nivel de seguridad significativo para clústeres en GKE. Para obtener más información, consulta Evita los roles y los grupos predeterminados.

Aquellos que deseen endurecer las API de descubrimiento de su clúster deben considerar una o más de las siguientes opciones:

Si ninguna de estas opciones es adecuada para tu caso práctico de GKE, debes tratar toda la información de descubrimiento de la API (es decir, el esquema de CustomResources, las definiciones de APIService y la información de descubrimiento alojada por los servidores de la API de extensión) como divulgada de manera pública

Ambas opciones permiten el acceso a la dirección IP del servidor de la API desde Cloud Run y Cloud Functions. Se está quitando este acceso, por lo que no debes confiar en que estos servicios se comunicarán con tu servidor de API. Para obtener más información, consulta la entrada de blog de Google Cloud.

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

Recomendación de CIS GKE Benchmark: 5.6.1. Crea límites administrativos entre los recursos que usan espacios de nombres

Brinda a los equipos el acceso a Kubernetes de privilegios mínimos mediante la creación de espacios de nombres o clústeres separados para cada equipo y entorno. Asigna centros de costos y etiquetas adecuadas a cada espacio de nombres para la rendición de cuentas y devolución del cargo. Solo brinda a los desarrolladores el nivel de acceso a su espacio de nombres que necesitan para implementar y administrar su aplicación, sobre todo en producción. Asigna las tareas que los usuarios deben realizar en el clúster y define los permisos que requieren para realizar cada tarea.

Para obtener más información sobre la creación de espacios de nombres, consulta la documentación de Kubernetes. Si deseas obtener prácticas recomendadas a la hora de planificar la configuración de RBAC, consulta Prácticas recomendadas para RBAC de GKE.

IAM y el Control de acceso según la función (RBAC) trabajan juntos, y una entidad debe tener permisos suficientes en cualquier nivel para trabajar con recursos en tu clúster.

Asigna las funciones de IAM adecuadas para GKE a grupos y usuarios con el fin de otorgar permisos a nivel de proyecto, y usa RBAC a fin de otorgar permisos a nivel de clúster y 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 del usuario con los recursos del clúster en la consola de Google Cloud. Para obtener más información, consulta Habilita el acceso y visualiza los recursos del clúster por espacio de nombres.

Restringe el tráfico entre pods mediante 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 según corresponda

De forma predeterminada, todos los pods en un clúster pueden comunicarse entre sí. Debes controlar la comunicación de pod a pod según sea necesario para tus cargas de trabajo.

Restringir el acceso de la red a los servicios hace que sea mucho más difícil para los atacantes moverse de forma lateral dentro de tu clúster, y también ofrece a los servicios cierta protección contra la denegación accidental o deliberada del servicio. Dos formas recomendadas para controlar el tráfico son:

  1. Usa Istio. Consulta Instala Istio en Google Kubernetes Engine si te interesa el balanceo de cargas, la autorización de servicios, las regulaciones, las cuotas, las métricas y más.
  2. Usa las Políticas de red de Kubernetes. Consulta Crea una política de red de clúster. Elige esto si buscas la funcionalidad básica de control de acceso que expone Kubernetes. A fin de implementar enfoques comunes para restringir el tráfico con las políticas de red, sigue la guía de implementación de los planos de seguridad de GKE Enterprise. En la documentación de Kubernetes, también puedes encontrar una excelente explicación sobre las implementaciones de nginx simples. Considera usar el registro de políticas de red para verificar que tus políticas de red funcionen según lo previsto.

Istio y la política de red pueden usarse en conjunto si es necesario.

Administración de Secrets

Recomendación de CIS GKE Benchmark: 6.3.1. Considera encriptar Secretos de Kubernetes con claves administradas en Cloud KMS

Debes proporcionar una capa adicional de protección para datos sensibles, como los secretos, que se almacenan en etcd. Para hacer esto, necesitas configurar un administrador de secretos que esté integrado en los clústeres de GKE. Algunas soluciones funcionarán tanto en GKE como en GKE en VMware, por lo que pueden ser más convenientes si ejecutas cargas de trabajo en varios entornos. Si eliges usar un administrador de secretos externo, como HashiCorp Vault, querrás configurarlo antes de crear tu clúster.

Tienes varias opciones para la administración secreta.

  • Puedes usar los secretos de Kubernetes de forma nativa en GKE. También tienes la opción de encriptarlos en la capa de aplicación con una clave que administres, mediante la Encriptación de secretos de la capa de la aplicación.
  • Puedes usar un administrador de secretos, como HashiCorp Vault. Cuando se ejecuta en un modo de HA endurecido, esto proporcionará una forma de administrar secretos coherente y lista para producción. Puedes autenticarte en HashiCorp Vault con una cuenta de servicio de Kubernetes o una cuenta de servicio de Google Cloud. Para obtener más información sobre el uso de GKE con Vault, consultaEjecuta HashiCorp Vault, y conéctate a él, en Kubernetes.

Las VM de GKE están encriptadas en la capa de almacenamiento de forma predeterminada, lo que incluye etcd.

Usa controladores de admisión para aplicar la política

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

De forma predeterminada, los pods en Kubernetes pueden operar con más funciones de las necesarias. Debes limitar las funciones del pod a solo las necesarias para esa carga de trabajo.

Kubernetes admite varios controles para restringir tus Pods de modo que se ejecuten solo con las capacidades otorgadas de forma explícita. Por ejemplo, Policy Controller está disponible para clústeres en 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 individuales.

Policy Controller es una función de GKE Enterprise que te permite aplicar y validar la seguridad en los clústeres de GKE a gran escala mediante políticas declarativas. Si deseas obtener información sobre cómo usar Policy Controller para aplicar controles declarativos en tu clúster de GKE, consulta Instala el controlador de políticas.

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 corresponden a los diferentes estándares de seguridad de Pods.

Restringe la capacidad de las cargas de trabajo de realizar modificaciones automáticas

Algunas cargas de trabajo de Kubernetes, en especial las del sistema, tienen permiso para realizar modificaciones automáticas. Por ejemplo, algunas cargas de trabajo se escalan automáticamente. Si bien es conveniente, esto puede permitir que un atacante que ya haya vulnerado un nodo pueda escalar más a fondo en el clúster. Por ejemplo, un atacante podría hacer que una carga de trabajo en el nodo se modifique a sí misma para ejecutarse como una cuenta de servicio con más privilegios que exista en el mismo espacio de nombres.

Lo ideal es que, en primer lugar, no se les otorgue a las cargas de trabajo permiso para modificarse a sí mismas. Cuando la modificación automática es necesaria, puedes limitar los permisos mediante la aplicación de restricciones de Gatekeeper o del controlador de políticas, como NoUpdateServiceAccount de la biblioteca de Gatekeeper de código abierto, que proporciona varias políticas de seguridad útiles.

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

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

Restringe el uso del tipo de volumen gcePersistentDisk obsoleto

El tipo de volumen gcePersistentDisk obsoleto te permite activar un disco persistente de Compute Engine en los Pods. Recomendamos que restrinjas el uso del tipo de volumen gcePersistentDisk en tus cargas de trabajo. GKE no realiza ninguna verificación de autorización de IAM en el Pod cuando se activa este tipo de volumen, aunque Google Cloud realiza verificaciones de autorización cuando se conecta el disco a la VM subyacente. Por lo tanto, un atacante que ya tiene la capacidad de crear Pods en un espacio de nombres puede acceder al contenido de los discos persistentes de Compute Engine en tu proyecto de Google Cloud.

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

Para evitar el uso del tipo de volumen gcePersistentDisk, aplica el modelo de referencia o la política restringida con el controlador de admisión PodSecurity o puedes definir una restricción personalizada en el controlador de políticas o en el controlador de admisión de Gatekeeper.

Para definir una restricción personalizada a fin de restringir este tipo de volumen, haz lo siguiente:

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

    Controlador de políticas

    Instala el controlador de políticas en tu clúster.

    El controlador de políticas es una función pagada para los usuarios de GKE. Policy Controller se basa en Gatekeeper de código abierto, pero también obtienes acceso a la biblioteca completa de plantillas de restricciones, a los paquetes de políticas y a la integración en los paneles de la consola de Google Cloud para ayudar a observar y mantener tus clústeres. Los paquetes de políticas son prácticas recomendadas bien definidas que puedes aplicar a tus clústeres, incluidos los paquetes basados en recomendaciones como las comparativas de CIS para Kubernetes.

    Gatekeeper

    Instala Gatekeeper en tu clúster.

    Para los clústeres Autopilot, abre el manifiesto gatekeeper.yaml de Gatekeeper en un editor de texto. Modifica el campo rules en la especificación MutatingWebhookConfiguration para reemplazar los caracteres comodín (*) por grupos de API específicos y nombres de recursos, 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 de Autopilot para instalar Gatekeeper. Esto es necesario porque, como medida de seguridad integrada, Autopilot no permite los caracteres comodín en los webhooks de admisión de mutación.

  2. Implementa la TemplateTemplate de restricción de tipos de volúmenes de políticas de seguridad de Pods:

    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 restringe los volúmenes a la lista del campo spec.parameters.volumes.

  4. Implementa la restricción:

    kubectl apply -f constraint.yaml

Supervisa la configuración del clúster

Debes auditar la configuración de tu clúster para detectar desviaciones de tu configuración definida.

Muchas de las recomendaciones que se incluyen en esta guía de endurecimiento, así como otras opciones de configuración incorrecta comunes, se pueden verificar de forma automática con las estadísticas del estado de la seguridad.

Valores predeterminados seguros

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

Protege los metadatos de nodo

Recomendaciones de CIS GKE Benchmark: 6.4.1. Asegúrate de que las API de metadatos de instancia de Compute Engine heredadas estén inhabilitadas y 6.4.2. Asegúrate de que el servidor de metadatos de GKE esté habilitado

Los extremos del servidor de metadatos de Compute Engine v0.1 y v1beta1 quedaron obsoletos y se cerraron el 30 de septiembre de 2020. Estos extremos no aplicaron encabezados de consulta de metadatos. Para ver el programa de baja, consulta Baja de los extremos del servidor de metadatos v0.1 y v1beta1.

Algunos ataques prácticos contra Kubernetes dependen del acceso al servidor de metadatos de la VM para extraer credenciales. Esos ataques se bloquean si usas la federación de identidades para cargas de trabajo para GKE o el ocultamiento de metadatos.

Deja los métodos de autenticación de clientes heredados inhabilitados

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

Existen varios métodos de autenticación en el servidor de la API de Kubernetes. En GKE, los métodos admitidos son tokens del portador de la cuenta de servicio, tokens de OAuth y certificados del cliente x509. GKE administra la autenticación con gcloud para ti a través del método del token de OAuth; de este modo, configura la configuración de Kubernetes, obtiene un token de acceso y lo mantiene actualizado.

Antes de la integración de GKE en OAuth, los únicos métodos de autenticación disponibles eran un certificado x509 generado una sola vez o una contraseña estática, pero ya no se recomiendan y deben inhabilitarse. Estos métodos presentan una superficie de ataque más amplia para el compromiso del clúster y se inhabilitaron de forma predeterminada desde la versión 1.12 de GKE. Si estás usando métodos de autenticación heredados, te recomendamos que los desactives. La autenticación con una contraseña estática es obsoleta y se quitó a partir de la versión 1.19 de GKE.

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

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

Por el momento, no hay forma de quitar el certificado de cliente ya emitido de un clúster existente, pero no tiene permisos si RBAC está habilitado y ABAC está inhabilitado.

Deja Cloud Logging habilitado

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 en Cloud Logging de forma predeterminada y deben permanecer configurados.

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

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

Deja la IU web de Kubernetes (Panel) inhabilitada

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

No debes habilitar la IU web de Kubernetes (Panel) cuando se ejecuta en GKE.

La IU web de Kubernetes (Panel) se encuentra respaldada por una Cuenta de servicio de Kubernetes con una gran cantidad de privilegios. La consola de Google Cloud ofrece muchas funciones similares, por lo que no necesitas estos permisos.

Para inhabilitar la IU web de Kubernetes, usa lo siguiente:

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

Deja ABAC inhabilitado

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

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

De forma predeterminada, ABAC está inhabilitado para los clústeres creados mediante la versión 1.8 de GKE y versiones posteriores. En Kubernetes, RBAC se usa para otorgar permisos a los recursos en el nivel de clúster y espacio de nombres. RBAC te permite definir funciones con reglas que contienen un conjunto de permisos. RBAC tiene importantes ventajas de seguridad en comparación con ABAC.

Si aún usas ABAC, primero revisa los requisitos previos para usar RBAC. Si actualizaste tu clúster desde una versión anterior y usas ABAC, debes actualizar la configuración de controles de acceso:

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

Para crear un nuevo clúster con la recomendación anterior, usa lo siguiente:

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

Deja habilitado el controlador de admisión DenyServiceExternalIPs

No inhabilites el controlador de admisión DenyServiceExternalIPs.

El controlador de admisión DenyServiceExternalIPs impide que los servicios usen ExternalIP 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 de GKE y posteriores. Para los clústeres que se actualizan a la versión 1.21 o posterior de GKE, puedes habilitar el controlador de admisión mediante el siguiente comando:

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

¿Qué sigue?