Comparativas de CIS

En esta página, se describe el enfoque que adopta Google Kubernetes Engine (GKE) para mejorar el cumplimiento de las comparativas del Centro para la seguridad en Internet (CIS) en Kubernetes y GKE. Esta página incluye la siguiente información:

  • Cómo configuramos el plano de control de GKE administrado a fin de que se ajuste a la comparativa de CIS para Kubernetes
  • Cómo puedes configurar tus nodos y cargas de trabajo de GKE para que cumplan con la comparativa de CIS para Google Kubernetes Engine (GKE)

Acerca de las comparativas de CIS

CIS lanza las siguientes comparativas que contienen lineamientos de configuración segura para Kubernetes:

  • Comparativas de CIS para Kubernetes: Se aplica al proyecto de código abierto de Kubernetes. Diseñado para proporcionar orientación para una variedad de implementaciones de Kubernetes autoadministradas y alojadas.
  • CIS GKE Benchmark: Establece lineamientos para la configuración segura de componentes que puedes controlar en los clústeres de GKE. Incluye recomendaciones específicas de GKE en Google Cloud.

Te recomendamos que priorices la comparativa de CIS para GKE, ya que es específica de GKE en Google Cloud. La comparativa de CIS para Kubernetes contiene muchas recomendaciones para los controles que no puedes ver ni modificar en GKE. Nuestro enfoque para la seguridad del clúster incluye mitigaciones que van más allá del alcance de la comparativa de código abierto de Kubernetes y pueden generar conflictos con esas recomendaciones.

Otras comparativas que se aplican a GKE

Además de la comparativa de CIS para GKE y la comparativa de CIS para Kubernetes, las siguientes comparativas se aplican a los sistemas operativos que están disponibles en GKE. Incluso si una comparativa de SO específica no aborda de manera explícita el uso de Kubernetes, debes hacer referencia a esa comparativa para obtener orientación de seguridad adicional.

El entorno de ejecución del contenedor predeterminado, containerd, no tiene una comparativa.

Modelo de responsabilidad compartida

Según el modelo de responsabilidad compartida de GKE, administramos los siguientes componentes por ti:

  • El plano de control, incluidas las VMs del plano de control, el servidor de la API y los componentes como la base de datos del estado del clúster (basada en etcd o Spanner), kube-controller-manager y kube-scheduler.
  • El sistema operativo del nodo.

Estos componentes existen en un proyecto que posee GKE, por lo que no puedes modificar ni evaluar ninguno de estos componentes en función de los controles de la comparativa de CIS correspondientes. Sin embargo, puedes evaluar y solucionar cualquier control de la comparativa de CIS que se aplique a los nodos trabajadores y las cargas de trabajo. Según el modelo de responsabilidad compartida de GKE, estos componentes son tu responsabilidad.

Nuestro enfoque de protección de GKE para la comparativa de CIS

GKE es una implementación administrada de Kubernetes de código abierto. Administramos por completo el plano de control y somos responsables de proteger la configuración de los componentes del plano de control. En la siguiente tabla, se describen algunas de nuestras decisiones que podrían afectar la puntuación de las comparativas de CIS:

Enfoque de seguridad de GKE
Autenticación
  • Algunos componentes de supervisión de GKE usan autenticación anónima para obtener métricas.
  • Algunos componentes del plano de control se inician mediante tokens estáticos que luego se usan para autenticarse en el servidor de la API. Estos tokens se generan cada vez que se inicia o se reinicia una VM.
Controladores de admisión

GKE inhabilita los siguientes controladores de admisión:

  • EventRateLimit: esta es una función alfa en Kubernetes
  • AlwaysPullImages: Este controlador proporciona cierta protección para las imágenes de registro privado en clústeres de multiusuarios no cooperativos, a costa de la creación de registros de imágenes en un punto único de fallo para crear Pods nuevos en el clúster.
  • SecurityContextDeny: Se prefiere el controlador de admisión de seguridad de Pods y está disponible en todas las ediciones de GKE. También puedes habilitar la aplicación de los estándares de seguridad de Pods con Policy Controller.
  • ImagePolicyWebhook: GKE inhabilita ImagePolicyWebhook de forma predeterminada, ya que tiene sus propios mecanismos de administración y seguridad de imágenes. Esto permite que GKE mantenga un control más estricto sobre el entorno y garantice que sus prácticas de seguridad se apliquen de forma coherente. Sin embargo, puedes usar la autorización binaria o el controlador de políticas para la administración de políticas.
Registros de auditoría GKE captura los registros de auditoría mediante la política de auditoría de GKE. Como resultado, no es necesario establecer ninguna marca de registro de auditoría del servidor de la API de Kubernetes.
Depuración GKE usa la generación de perfiles para la depuración.
Encriptación
etcd

En Kubernetes de código abierto, la base de datos de estado del clúster usa etcd. En GKE, la base de datos de backend que almacena el estado del clúster es una de las siguientes tecnologías:

  • etcd: El clúster ejecuta instancias de etcd en el plano de control.
  • Spanner: GKE almacena el estado del clúster en una base de datos basada en Spanner que está separada de las VMs del plano de control.

Todos los clústeres de GKE publican la API de etcd en las VMs del plano de control. Todas las interacciones del cliente con la API de Kubernetes son las mismas que en Kubernetes de código abierto. Según la tecnología de base de datos que sea el backend de la API de etcd en tu clúster, es posible que observes discrepancias en cualquier puntuación relacionada con etcd en la comparativa de CIS para Kubernetes de código abierto.
kubelet
  • GKE habilita el puerto de solo lectura de kubelet no autenticado. Puedes inhabilitar el puerto configurando --no-autoprovisioning-enable-insecure-kubelet-readonly-port. El puerto de solo lectura se inhabilitará de forma predeterminada en una versión futura después de que tengas tiempo para migrar.
  • El modo GKE Standard permite que tus cargas de trabajo modifiquen los valores predeterminados del kernel si es necesario.
  • GKE limita la cantidad de eventos de Kubernetes en kubelet para reducir el riesgo de ataques de denegación del servicio.
  • GKE usa mTLS para proteger el tráfico entre kubelet y el servidor de la API.
  • GKE rota los certificados de servidor de forma predeterminada y los certificados de cliente cuando los nodos de GKE protegidos están habilitados.
  • GKE usa el conjunto predeterminado de algoritmos de cifrado permitidos de golang, que también es la configuración predeterminada para Kubernetes.

Evalúa GKE en función de las comparativas de CIS

Puedes automatizar la evaluación de tus clústeres en comparación con las comparativas mediante uno de los siguientes métodos:

  • Comparativa de GKE de CIS
    • Ejecuta kube-bench para evaluar los nodos trabajadores en comparación con la comparativa. Para obtener más detalles, consulta el repositorio de GitHub de kube-bench.
    • Usa una herramienta de terceros como Twistlock Defender para evaluar los nodos con la comparativa.
  • Comparativa de Kubernetes de CIS: Ejecuta kube-bench a fin de evaluar los nodos trabajadores en comparación con la comparativa. No puedes evaluar el plano de control administrado en función de esas recomendaciones en la comparativa.

¿Qué sigue?