Seguridad del plano de control

En este documento, se describe cómo Google Kubernetes Engine (GKE) ayuda a proteger los componentes del plano de control de tu clúster. En este documento, se supone que tienes conocimientos sobre lo siguiente:

Este documento está dirigido a especialistas en seguridad que desean comprender cómo Google administra los componentes del plano de control de GKE y las medidas de seguridad implementadas para evaluar el riesgo de manera eficaz y garantizar la seguridad de sus implementaciones de GKE.

GKE incluye funciones de seguridad integradas, como un SO reforzado, una arquitectura y un aislamiento sólidos, acceso seguro al plano de control, seguridad para la base de datos de estado del clúster basada en etcd o Spanner, autoridad de certificación y confianza del clúster, y administración de vulnerabilidades y parches.

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, el almacenamiento de objetos de la API de Kubernetes y otros controladores. Google es responsable de proteger 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 de la base de datos del estado del clúster

En Google Cloud, el contenido del cliente se encripta en la capa del sistema de archivos de forma predeterminada. Esta encriptación incluye la infraestructura que aloja la base de datos basada en etcd o Spanner que almacena el estado de los objetos de la API de Kubernetes en tu clúster. Para obtener más información sobre la base de datos de estado del clúster, consulta Arquitectura del clúster de GKE.

La base de datos de estado del clúster almacena la configuración de cada objeto de la API de Kubernetes en tu clúster como pares clave-valor. GKE usa puertos TCP específicos en las VMs del plano de control para los siguientes tipos de comunicación con la base de datos de estado del clúster:

  • Clientes de la API de etcd: GKE entrega la API de etcd en cada VM del plano de control. Los clientes de la API de etcd en el plano de control, como el servidor de la API de Kubernetes, usan uno de los siguientes puertos:

    • Puerto 2379: Este puerto se usa cuando GKE almacena el estado del clúster en instancias de la base de datos de etcd que se ejecutan en cada VM del plano de control.
    • Puerto 3379: Este puerto se usa cuando GKE almacena el estado del clúster en una base de datos de Spanner que está separada del plano de control.

    El puerto que usan los clientes de la API de etcd está vinculado a la interfaz de la red de bucle invertido local y solo se puede acceder a él desde la VM del plano de control que ejecuta el servidor de la API de Kubernetes.

  • Instancias de la base de datos de etcd: Si las VMs del plano de control ejecutan instancias de la base de datos de etcd, los servidores de la API de etcd en cada VM usan el puerto 2380 para comunicarse entre sí. El tráfico en el puerto 2380 entre las instancias de la base de datos de etcd en varias VMs del plano de control (como en los clústeres regionales) se encripta con TLS mutua. Con TLS mutuo, cada servidor debe demostrar su identidad al otro.

    El puerto 2380 no se usa en los clústeres que almacenan el estado del clúster en una base de datos de Spanner, ya que la base de datos no se ejecuta en las VMs del plano de control.

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. Las claves raíz de esta CA se distribuyen a los metadatos de las VMs que ejecutan el servidor de la API de Kubernetes. La TLS protege la comunicación entre nodos y el servidor de API de Kubernetes. Cada clúster también tiene su propia CA para la API de etcd y, si el clúster ejecuta instancias de la base de datos de etcd, para el tráfico entre las instancias de etcd. 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 se analizaron en las secciones anteriores. En esta sección y en la sección Qué puedes configurar, se describen las funciones de seguridad que puedes supervisar y configurar.

  • Registros de auditoría: El registro de auditoría está habilitado de forma predeterminada. 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 registro en el Explorador de registros en la consola deGoogle Cloud . También puedes usar BigQuery para ver y analizar estos registros.

  • Integridad de la imagen de VM del plano de control: GKE agrega registros detallados de los eventos de creación y arranque de la VM del nodo a Cloud Logging. Además, publicamos VSA de SLSA en GitHub que corresponden a imágenes de máquinas de nodo trabajador y de plano de control. Puedes verificar que tus VMs usen imágenes del SO que tengan VSA correspondientes y verificar la integridad de inicio de cada VM del plano de control.

    Para realizar la verificación de integridad de la VM, consulta Cómo verificar la integridad de la VM del plano de control de GKE.

Qué puedes configurar

Si bien GKE administra la mayor parte del plano de control por ti, puedes controlar lo siguiente:

  • Acceso al plano de control: El plano de control tiene dos tipos de extremos para el acceso al clúster:

    • Extremo basado en DNS
    • Extremos basados en IP

    Según la configuración predeterminada, el servidor de API de Kubernetes usa una dirección IP externa. Puedes proteger el servidor de API de Kubernetes si habilitas un extremo basado en DNS para acceder al plano de control. Puedes controlar quién puede acceder al extremo de DNS con los Controles del servicio de VPC, que te permiten definir un parámetro de seguridad para todas las APIs de Google en tu proyecto. Si usas extremos basados en IP para acceder al plano de control, te recomendamos que uses redes autorizadas y que inhabilite el acceso al extremo externo del plano de control. Para obtener más información sobre el aislamiento de red, consulta Acerca de la personalización del aislamiento de red.

  • Autenticación: Puedes controlar la autenticación del clúster en GKE si usas IAM como proveedor de identidad. Para 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.

  • Rotación de credenciales: Rota la autoridad certificadora (CA) del clúster y los certificados TLS de forma periódica realizando una rotación de credenciales. GKE también rota la dirección IP de tu servidor de la API de Kubernetes durante este proceso. Para obtener más información, consulta rotación de credenciales.

Además, si tu organización tiene requisitos estrictos de cumplimiento o políticas relacionados con el plano de control, la autoridad del plano de control de GKE es un conjunto de funciones que te brindan mayor visibilidad y control sobre aspectos específicos del plano de control, incluidos los siguientes:

  • Ejecuta tus propias entidades certificadoras y claves para la emisión de identidades con Cloud KMS y CA Service.
  • Encripta los discos de arranque de etcd y del plano de control con tus propias claves en Cloud KMS.

Para obtener detalles sobre por qué usarías estas funciones y todas las capacidades disponibles, consulta Acerca de la autoridad del plano de control de GKE.

¿Qué sigue?