Seguridad del plano de control

En esta página se describe cómo protege Google Kubernetes Engine (GKE) los componentes del plano de control de tu clúster. Descubre las funciones de seguridad integradas en GKE, como un SO reforzado, una arquitectura y un aislamiento robustos, un 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 gestión de vulnerabilidades y parches.

Esta página está dirigida a especialistas en seguridad que quieran saber cómo gestiona Google los componentes del plano de control de GKE y qué medidas de seguridad se han implementado para evaluar los riesgos de forma eficaz y garantizar la seguridad de sus implementaciones de GKE.

Según el modelo de responsabilidad compartida, Google gestiona los componentes del plano de control de GKE. 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 en función de tus requisitos. Eres responsable de proteger tus nodos, contenedores y pods.

Sistema operativo reforzado

Los componentes del plano de control de GKE se ejecutan en Container-Optimized OS, un sistema operativo reforzado diseñado por Google. Para obtener una descripción detallada de las funciones de seguridad integradas en Container-Optimized OS, consulta la información general sobre la 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 propiedad de Google, en un proyecto gestionado por Google. Cada instancia ejecuta estos componentes para un solo clúster.

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

Acceso al plano de control de tu proyecto

GKE usa un agente de servicio llamado agente de servicio de Kubernetes Engine para activar recursos de clúster en tu nombre, como nodos, discos y balanceadores de carga. A la cuenta de servicio se le concede automáticamente el rol 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:

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

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

Acceso de administrador al clúster

Las sesiones SSH de los ingenieros de fiabilidad de sitios de Google se registran mediante la infraestructura de auditoría interna de Google, que está disponible para análisis forenses y respuesta de seguridad. Para obtener más información, consulta la sección Acceso administrativo del informe sobre seguridad de Google.

Seguridad de la base de datos de estado del clúster

En Google Cloud, el contenido de los clientes se cifra de forma predeterminada en la capa del sistema de archivos. Este cifrado 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 del estado del clúster, consulta el artículo sobre la arquitectura de clústeres de GKE.

La base de datos de estado del clúster almacena la configuración de cada objeto de la API de Kubernetes de 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 etcd: GKE sirve la API etcd en todas las VMs del plano de control. Los clientes de la API etcd del 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 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 independiente del plano de control.

    El puerto que usan los clientes de la API de etcd está enlazado a la interfaz de red de bucle 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 etcd: si las VMs del plano de control ejecutan instancias de la base de datos etcd, los servidores de la API etcd de cada VM usan el puerto 2380 para comunicarse entre sí. El tráfico del puerto 2380 entre las instancias de la base de datos etcd de varias VMs del plano de control (como en los clústeres regionales) se cifra mediante TLS mutuo. 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 porque la base de datos no se ejecuta en las VMs del plano de control.

Autoridad de certificación y confianza del clúster

Cada clúster tiene su propia autoridad de certificación (CA) raíz. Un servicio interno de Google gestiona las claves raíz de esta AC. 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 comunicación entre los nodos y el servidor de la API de Kubernetes está protegida por TLS. Cada clúster también tiene su propia CA para la API etcd y, si el clúster ejecuta instancias de la base de datos etcd, para el tráfico entre instancias de etcd. Para obtener más información, consulta Confianza de clústeres.

Gestión de vulnerabilidades y parches

GKE cumple los estándares de Google para probar, calificar e implementar gradualmente los cambios en el plano de control. De esta forma, se minimiza el riesgo de que un componente del plano de control deje de estar disponible. GKE se rige por un acuerdo de nivel de servicio que define muchos aspectos de la disponibilidad.

Un equipo de ingenieros de fiabilidad de sitios de Google gestiona los componentes del plano de control de GKE, que se mantienen actualizados con los últimos parches de seguridad. Esto incluye parches para el sistema operativo host, los componentes de Kubernetes y los contenedores que se ejecutan en las VMs del plano de control.

GKE aplica rápidamente nuevas correcciones a nivel de kernel, SO y Kubernetes a las VMs del plano de control. Cuando contienen correcciones para vulnerabilidades conocidas, se puede consultar información adicional en los boletines de seguridad de GKE. GKE analiza todos los contenedores del sistema Kubernetes y los contenedores específicos de GKE en busca de vulnerabilidades mediante Artifact Analysis y mantiene los contenedores parcheados, lo que beneficia a todo el ecosistema de Kubernetes.

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

Qué puedes ver

Google gestiona las funciones de seguridad que se han descrito en las secciones anteriores. En esta sección y en la sección Opciones que puedes configurar se describen las funciones de seguridad que puedes monitorizar y configurar.

  • Registros de auditoría: registros de auditoría está habilitado de forma predeterminada. De esta forma, se obtiene un registro detallado, disponible en Google Cloud Observability, de las llamadas realizadas al servidor de la API de Kubernetes. Puedes ver las entradas de registro en el explorador de registros de 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 añade registros detallados de los eventos de creación y arranque de VMs de nodos a Cloud Logging. Además, publicamos VSAs de SLSA en GitHub que corresponden a imágenes de máquina del plano de control y del nodo de trabajador. Puedes verificar que tus VMs usen imágenes de SO que tengan VSAs correspondientes y verificar la integridad del arranque de cada VM del plano de control.

    Para verificar la integridad de las VMs, consulta Verificar la integridad de las VMs del plano de control de GKE.

Opciones que puedes configurar

Aunque GKE gestiona la mayor parte del plano de control, puedes controlar lo siguiente:

  • Acceso al plano de control: el plano de control tiene dos tipos de endpoints para acceder al clúster:

    • Endpoint basado en DNS
    • Endpoints basados en IP

    De forma predeterminada, el servidor de la API de Kubernetes usa una dirección IP externa. Puedes proteger el servidor de la API de Kubernetes habilitando un endpoint basado en DNS para acceder al plano de control. Puedes controlar quién puede acceder al endpoint DNS con Controles de Servicio de VPC, que te permite definir un parámetro de seguridad para todas las APIs de Google de tu proyecto. Si usas endpoints basados en IP para acceder al plano de control, te recomendamos que uses redes autorizadas y que inhabilites el acceso al endpoint externo del plano de control. Para obtener más información sobre el aislamiento de redes, consulta el artículo Acerca de la personalización del aislamiento de redes.

  • Autenticación: puedes gestionar la autenticación de clústeres en GKE usando IAM como proveedor de identidades. 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 de certificación (CA) del clúster y los certificados TLS periódicamente 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 de políticas relacionados con el plano de control, la autoridad del plano de control de GKE es un conjunto de funciones que te proporciona una mayor visibilidad y control sobre aspectos específicos del plano de control, como los siguientes:

  • Ejecuta tus propias ACs y claves para emitir identidades con Cloud KMS y el servicio de ACs.
  • Encripta los discos de arranque de etcd y del plano de control con tus propias claves en Cloud KMS.

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

Siguientes pasos