Seguridad del plano de control

En este documento, se describe cómo se aseguran los componentes del plano de control del clúster en Google Kubernetes Engine.

Según el Modelo de responsabilidad compartida, Google administra los componentes del plano de control de GKE por ti. El plano de control incluye el servidor de la API de Kubernetes, etcd y varios controladores. Google es responsable de asegurar el plano de control, aunque es posible que puedas configurar determinadas opciones de acuerdo con tus requisitos. Eres responsable de proteger tus nodos, contenedores y pods.

Sistema operativo endurecido

Los componentes del plano de control de GKE se ejecutan en Container-Optimized OS, que es un sistema operativo de seguridad endurecido diseñado por Google. Para obtener una descripción detallada de las características de seguridad integradas en Container-Optimized OS, consulta la descripción general de seguridad de Container-Optimized OS.

Arquitectura y aislamiento

En un clúster de GKE, los componentes del plano de control se ejecutan en instancias de Compute Engine que pertenecen a Google, en un proyecto administrado por este. Cada instancia ejecuta estos componentes para un solo cliente.

La autenticación en el servidor de API de Kubernetes y etcd se realiza de la misma manera que para los otros servicios de Google Cloud. La seguridad de transporte de la capa de la aplicación (ALTS) protege estas comunicaciones.

Acceso de administrador al clúster

Las sesiones SSH que realizan los ingenieros especializados en confiabilidad de sitios de Google son registros de auditoría llevados a cabo en toda la infraestructura de auditoría interna de Google que está disponible para respuesta forense y de seguridad. Para obtener más información, consulta Acceso de administrador en el informe de seguridad de Google.

Seguridad etcd

En Google Cloud Platform, se encripta el contenido del cliente en la capa del sistema de archivos de forma predeterminada. Por lo tanto, los discos que alojan el almacenamiento de etcd para los clústeres de GKE se encriptan en la capa del sistema de archivos. Para obtener más información, consulta Encriptación en reposo.

etcd escucha en dos puertos TCP. El puerto 2379 es para clientes etcd, como el servidor de la API de Kubernetes. El puerto 2379 está vinculado a la interfaz de la red de bucle invertido local, por lo que solo se puede acceder desde la VM que ejecuta el servidor de la API de Kubernetes. El puerto 2380 es para la comunicación de servidor a servidor. El tráfico en el puerto 2380 se encripta mediante TLS mutua. Es decir, cada servidor debe demostrar su identidad al otro. En un clúster regional, la TLS mutua encripta la comunicación entre los servidores etcd para establecer cuórum.

Autoridad certificada y confianza del clúster

Cada clúster tiene su propia autoridad certificada raíz (CA). Un servicio interno de Google administra las claves raíz de esta CA. Cada clúster también tiene su propia CA para etd. Las claves de raíz para la CA de etcd se distribuyen entre los metadatos de las VM que ejecutan el servidor de API de Kubernetes. La TLS protege la comunicación entre nodos y el servidor de API de Kubernetes. Para obtener más información, consulta Confianza del clúster .

Vulnerabilidad y administración de parches

GKE se adhiere a los estándares de Google para las pruebas, las calificaciones y las implementaciones graduales de los cambios en el plano de control. Esto minimiza el riesgo de que un componente del plano de control no esté disponible. GKE se adhiere al Acuerdo de Nivel de Servicio que define varios aspectos de la disponibilidad.

Un equipo de ingenieros especializados en la confiabilidad de sitios administra los componentes del plano de control de GKE y los mantiene actualizados con los parches de seguridad más recientes. Esto incluye los parches para el sistema operativo host, los componentes de Kubernetes y los contenedores que se ejecutan en las VM del plano de control.

GKE aplica nuevas correcciones a nivel de kernel, SO y Kubernetes rápidamente para controlar VM planas. Cuando estos contienen correcciones para vulnerabilidades conocidas, hay información adicional disponible en los Boletines de seguridad de GKE. GKE analiza todos los sistemas Kubernetes y los contenedores específicos de GKE en busca de vulnerabilidades con el Análisis de vulnerabilidades de Container Registry y mantiene los contenedores con parches, lo que beneficia a todo el ecosistema de Kubernetes.

Los ingenieros de Google participan en la búsqueda, reparación y divulgación de errores de seguridad de Kubernetes. Google paga a los investigadores de seguridad externos, a través del Programa de recompensas por detección de vulnerabilidades en todos los productos de Google, por buscar errores de seguridad. En algunos casos, como con la vulnerabilidad en dnsmasq en octubre de 2017, GKE pudo aplicar un parche en todos los clústeres en ejecución antes de que la vulnerabilidad se hiciera pública.

Qué puedes ver

Google administra las características de seguridad que analizamos con anterioridad en este tema. En esta y en la siguiente sección, se analizan las características de seguridad que puedes supervisar y configurar.

El Registro de auditoría se habilita de forma predeterminada para los clústeres creados desde la actualización de la versión 1.8.3. Esto proporciona un registro detallado disponible en Stackdriver de llamadas realizadas al servidor de la API de Kubernetes. Puedes ver las entradas de registros en la página de registros en GCP Console. También puedes usar BigQuery para ver y analizar estos registros.

Qué puedes configurar

Según la configuración predeterminada, el servidor de API de Kubernetes usa una dirección IP pública. Puedes proteger el servidor de API de Kubernetes si usas las redes autorizadas de instancia principal y los clústeres privados que te permitan asignar una dirección IP privada al servidor de API de Kubernetes, además de inhabilitar el acceso en la dirección IP pública.

Puedes controlar la autenticación del clúster en GKE si usas Cloud IAM como proveedor de identidad. Para asegurarte de haber inhabilitado la autenticación básica, debes establecer un nombre de usuario y contraseña vacíos para la configuración de MasterAuth. En la misma configuración, puedes inhabilitar el certificado de cliente, lo que garantiza que tengas una clave menos que considerar cuando bloquees el acceso al clúster.

Puedes mejorar la seguridad de tu plano de control si realizas la rotación de credenciales de forma habitual. Cuando se inicia la rotación de credenciales, se rotan de forma automática los certificados TLS y la autoridad certificada del clúster. GKE también rota la dirección IP de tu servidor de la API de Kubernetes. Para obtener más información, consulta Control de acceso según la función y Rotación de credenciales.

Qué sigue

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Kubernetes Engine