Seguridad del plano de control

En este documento, se describe cómo Google Kubernetes Engine (GKE) protege los componentes del plano de control de tu clúster.

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 otros 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 funciones 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.

Para obtener detalles sobre cómo los componentes del clúster se autentican entre sí, consulta Confianza del clúster.

Controla el acceso al plano de tu proyecto

GKE usa un agente de servicio llamado Agente del servicio de Kubernetes Engine para activar los recursos del clúster en tu nombre, como nodos, discos y balanceadores de cargas. La cuenta de servicio recibe automáticamente el rol de agente de servicio de Kubernetes Engine (roles/container.serviceAgent) en tu proyecto.

El agente de servicio de Kubernetes Engine tiene la siguiente dirección de correo electrónico:

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

En esta dirección de correo electrónico, PROJECT_NUMBER es tu número de proyecto.

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, 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 de manera gradual de los cambios al 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 de Kubernetes y los contenedores específicos de GKE en busca de vulnerabilidades con Artifact Analysis 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 también 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, para 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 versión 1.8.3 de GKE. Esto proporciona un registro detallado de las llamadas realizadas al servidor de la API de Kubernetes que está disponible en Google Cloud Observability. Puedes ver las entradas de registros en el Explorador de registros en la consola de Google Cloud. 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 redes autorizadas y clústeres privados, que te permiten asignar una dirección IP privada al servidor de API de Kubernetes y, además, inhabilitar el acceso en la dirección IP pública.

Puedes controlar la autenticación del clúster en GKE si usas IAM como proveedor de identidad. A fin de mejorar la seguridad de la autenticación, la autenticación básica y la emisión de certificados de cliente están inhabilitadas de forma predeterminada para los clústeres creados con GKE 1.12 y versiones posteriores.

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 basado en funciones (RBAC) y Rotación de credenciales.

¿Qué sigue?