CIS Benchmarks

En esta página se describe el enfoque que adopta Google Kubernetes Engine (GKE) para mejorar el cumplimiento de los estándares del Center for Internet Security (CIS) para Kubernetes y GKE. Esta página incluye la siguiente información:

  • Cómo configuramos el plano de control de GKE gestionado para que cumpla la comparativa de CIS Kubernetes
  • Cómo configurar los nodos y las cargas de trabajo de GKE para que cumplan el benchmark de CIS Google Kubernetes Engine (GKE)

Acerca de CIS Benchmarks

CIS publica los siguientes estándares que contienen directrices de configuración segura para Kubernetes:

  • CIS Kubernetes Benchmark: se aplica al proyecto de código abierto Kubernetes. Su objetivo es proporcionar directrices para diversas implementaciones de Kubernetes autogestionadas y alojadas.
  • Benchmark de GKE de CIS: establece directrices para la configuración segura de los componentes que puedes controlar en los clústeres de GKE. Incluye recomendaciones específicas para GKE en Trusted Cloud by S3NS.

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

Otros comparativas que se aplican a GKE

Además de los estándares CIS GKE Benchmark y CIS Kubernetes Benchmark, se aplican los siguientes estándares a los sistemas operativos disponibles en GKE. Aunque una prueba comparativa de un SO específico no aborde explícitamente el uso de Kubernetes, debes hacer referencia a esa prueba para obtener más información sobre seguridad.

El entorno de ejecución de contenedores predeterminado, containerd, no tiene ninguna prueba comparativa.

Modelo de responsabilidad compartida

Según el modelo de responsabilidad compartida de GKE, gestionamos los siguientes componentes:

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

Estos componentes se encuentran en un proyecto propiedad de GKE, por lo que no puedes modificar ni evaluar ninguno de estos componentes en comparación con los controles de CIS Benchmark correspondientes. Sin embargo, puedes evaluar y corregir los controles de la prueba comparativa del CIS que se apliquen a tus nodos de trabajador y a tus cargas de trabajo. Según el modelo de responsabilidad compartida de GKE, estos componentes son tu responsabilidad.

Cómo abordamos la seguridad de GKE para el benchmark del CIS

GKE es una implementación gestionada de Kubernetes de código abierto. Gestionamos 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 pueden afectar a la puntuación de las comparativas del CIS:

Estrategia de seguridad de GKE
Autenticación
  • Algunos componentes de monitorización de GKE usan la autenticación anónima para obtener métricas.
  • Algunos componentes del plano de control se inician mediante tokens estáticos, que se usan para autenticar 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 se trata de una función alfa de Kubernetes.
  • AlwaysPullImages este controlador proporciona cierta protección para las imágenes de registro privadas en clústeres multiinquilino no cooperativos, pero a costa de que los registros de imágenes sean un único punto de fallo para crear nuevos pods en el clúster.
  • SecurityContextDeny se recomienda el controlador de admisión de seguridad de pods, que está disponible en todas las ediciones de GKE. También puedes habilitar la aplicación de los estándares de seguridad de pods mediante Policy Controller.
  • ImagePolicyWebhook GKE inhabilita ImagePolicyWebhook de forma predeterminada porque tiene sus propios mecanismos para gestionar imágenes y protegerlas. De esta forma, GKE puede mantener un control más estricto sobre el entorno y asegurarse de que sus prácticas de seguridad se apliquen de forma coherente. Sin embargo, puedes usar Autorización binaria o Policy Controller para gestionar las políticas.
Registros de auditoría GKE registra los registros de auditoría mediante la política de auditoría de GKE. Por lo tanto, no es necesario definir ninguna marca de registro de auditoría del servidor de la API de Kubernetes.
Depuración GKE usa la creación de perfiles para depurar errores.
Cifrado
etcd

En Kubernetes de código abierto, la base de datos de estado del clúster usa etcd. En GKE, la base de datos 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 sirven la API de etcd en las VMs del plano de control. Las interacciones de los clientes con la API de Kubernetes son las mismas que en Kubernetes de código abierto. En función de la tecnología de base de datos que sea el backend de la API etcd de tu clúster, es posible que observes discrepancias en cualquier puntuación relacionada con etcd en la comparativa de Kubernetes de CIS 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 darte un tiempo para migrar.
  • El modo estándar de GKE permite que tus cargas de trabajo modifiquen los valores predeterminados del kernel si es necesario.
  • GKE limita el número de eventos de Kubernetes en kubelet para reducir el riesgo de ataques de denegación de servicio.
  • GKE usa mTLS para proteger el tráfico entre el kubelet y el servidor de la API.
  • GKE rota los certificados de servidor de forma predeterminada y los certificados de cliente cuando se habilitan los nodos de GKE blindados.
  • GKE usa el conjunto de cifrado predeterminado de Go, que también es el predeterminado de Kubernetes.

Evaluar GKE en comparación con los CIS Benchmarks

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

  • CIS GKE Benchmark:
    • Ejecuta kube-bench para evaluar los nodos de trabajador en comparación con la comparativa. Para obtener más información, consulta el repositorio de GitHub kube-bench.
    • Utilice una herramienta de terceros, como Twistlock Defender, para evaluar los nodos en comparación con la prueba de rendimiento.
  • Comparativa de CIS Kubernetes: ejecuta kube-bench para evaluar los nodos de trabajador en comparación con la comparativa. No puedes evaluar el plano de control gestionado con respecto a esas recomendaciones en la comparativa.

Siguientes pasos