Confianza del clúster

En este documento, se describe el modelo de confianza en los clústeres de Google Kubernetes Engine (GKE), incluida la comunicación dentro de los clústeres y cómo se autentican las solicitudes para componentes como los planos de control. En este documento, se supone que tienes conocimientos sobre lo siguiente:

Este documento está dirigido a los especialistas en seguridad que desean comprender el modelo de confianza del clúster de GKE. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Comunicación intraclúster

GKE aplica varios mecanismos de seguridad al tráfico entre los componentes del clúster, de la siguiente manera:

  • Tráfico entre el plano de control y los nodos: El plano de control se comunica con un nodo para administrar contenedores. Cuando el plano de control envía una solicitud (por ejemplo, kubectl logs) a los nodos, la solicitud se envía a través de un túnel de proxy de Konnectivity. Las solicitudes que envía el plano de control se autentican y protegen con TLS. Cuando un nodo envía una solicitud al plano de control, por ejemplo, desde el kubelet al servidor de la API, esa solicitud se autentica y encripta con TLS mutuo (mTLS).

    Todos los clústeres recién creados y actualizados usan TLS 1.3 para la comunicación del plano de control a los nodos. TLS 1.2 es la versión mínima admitida para la comunicación del plano de control a los nodos.

  • Tráfico entre nodos: Los nodos son VMs de Compute Engine. Las conexiones entre los nodos dentro de la red de producción de Google Cloud se autentican y encriptan. Para obtener más información, consulta la sección de VM a VM del informe de encriptación en tránsito.

  • Tráfico entre Pods: Cuando un Pod envía una solicitud a otro Pod, ese tráfico no se autentica de forma predeterminada. GKE encripta el tráfico entre Pods en diferentes nodos en la capa de red. El tráfico entre Pods en el mismo nodo no se encripta de forma predeterminada. Para obtener detalles sobre la encriptación de la capa de red, consulta Google Cloud Autenticación y encriptación de redes virtuales.

    Puedes restringir el tráfico de Pod a Pod con unNetworkPolicy y puedes encriptar todo el tráfico de Pod a Pod, incluido el tráfico en el mismo nodo, con una malla de servicios como Cloud Service Mesh o con un método diferente de encriptación de la capa de la aplicación.

  • Tráfico entre los componentes del plano de control: El tráfico entre los distintos componentes que se ejecutan en el plano de control se autentica y encripta con TLS. El tráfico nunca sale de una red propiedad de Google que está protegida por firewalls.

Raíz de confianza

GKE tiene la siguiente configuración:

  • La autoridad certificada (CA) raíz del clúster se usa para validar el servidor de API y los certificados de cliente de Kubelets. Es decir, los planos de control y los nodos tienen la misma raíz de confianza. Cualquier kubelet dentro del grupo de nodos del clúster puede solicitar un certificado de esta CA con la API de certificates.k8s.io mediante el envío de una solicitud de firma de certificado. La CA raíz tiene una vida útil limitada, como se describe en la sección Ciclo de vida de la CA raíz del clúster.
  • En los clústeres que ejecutan instancias de la base de datos etcd en las VMs del plano de control, se usa una CA de pares de etcd independiente por clúster para establecer la confianza entre las instancias de etcd.
  • En todos los clústeres de GKE, se usa una CA de la API de etcd independiente para establecer la confianza entre el servidor de la API de Kubernetes y la API de etcd.

Servidor API y kubelets

El servidor de la API y kubelets confían en la CA raíz del clúster para obtener confianza. En GKE, el certificado de la API del plano de control está firmado por la CA raíz del clúster. Cada clúster ejecuta su propia CA, de modo que si se vulnera la CA de un clúster, ninguna otra CA del clúster se vea afectada.

Un servicio interno de Google administra las claves de raíz para esta CA, las cuales no son exportables. Este servicio acepta solicitudes de firma de certificado, incluidas las de los kubelets en cada clúster de GKE. Incluso si el servidor de la API en un clúster estuviera comprometido, la CA no lo estaría, por lo que no se verían afectados otros clústeres.

Cada nodo del clúster recibe un Secret compartido en el momento de su creación, el cual puede usar para enviar solicitudes de firma de certificado a la CA de raíz del clúster y obtener certificados de cliente de kubelet. Kubelet usa estos certificados para autenticar sus solicitudes en el servidor de la API. Los Pods en el nodo pueden acceder a este secreto compartido, a menos que habilites Nodos de GKE protegidos o la federación de identidades para cargas de trabajo para GKE.

Duración de la CA raíz del clúster

La CA raíz del clúster tiene una vida útil limitada, después de lo cual los certificados firmados por la CA vencida no son válidos. Verifica la fecha de vencimiento aproximada de la CA del clúster siguiendo las instrucciones que se indican en Verifica la vida útil de la credencial.

Debes rotar de forma manual tus credenciales antes de que venza la CA raíz existente. Si la CA vence y no rotas tus credenciales, es posible que el clúster ingrese en un estado irrecuperable. GKE tiene los siguientes mecanismos para evitar que haya clústeres irrecuperables:

  • El clúster entra en un estado de DEGRADED siete días antes del vencimiento de la CA

  • GKE intenta rotar la credencial de forma automática 30 días antes del vencimiento de la CA. Esta rotación automática ignora los períodos de mantenimiento y puede causar interrupciones a medida que GKE vuelve a crear los nodos para usar credenciales nuevas. Los clientes externos, como kubectl en entornos locales, no funcionarán hasta que los actualices para usar las credenciales nuevas.

Para obtener información sobre cómo realizar una rotación, consulta Rota las credenciales del clúster.

Almacenamiento del estado del clúster

Los clústeres de GKE almacenan el estado de los objetos de la API de Kubernetes como pares clave-valor en una base de datos. El servidor de la API de Kubernetes en tu plano de control interactúa con esta base de datos a través de la API de etcd. GKE usa una de las siguientes tecnologías para ejecutar la base de datos de estado del clúster:

  • etcd: El clúster usa instancias de etcd que se ejecutan en las VMs del plano de control.
  • Spanner: El clúster usa una base de datos de Spanner que se ejecuta fuera de las VMs del plano de control.

Independientemente de la tecnología de base de datos que use un clúster, cada clúster de GKE entrega la API de etcd en el plano de control. Para encriptar el tráfico que involucra la base de datos de estado del clúster, GKE usa una o ambas de las siguientes CAs por clúster:

  • CA de la API de etcd: Se usa para firmar certificados para el tráfico hacia y desde los extremos de la API de etcd. En cada clúster de GKE, se ejecuta una CA de la API de etcd.
  • CA de pares de etcd: Se usa para firmar certificados para el tráfico entre instancias de la base de datos de etcd en el plano de control. Una CA de pares de etcd se ejecuta en cualquier clúster que use bases de datos de etcd. Los clústeres que usan bases de datos de Spanner no usan la CA de pares de etcd.

Las claves de raíz para la CA de la API de etcd se distribuyen a los metadatos de cada instancia de Compute Engine en la que se ejecuta el plano de control. La CA de la API de etcd no se comparte entre clústeres.

Los certificados de la CA de etcd son válidos por cinco años. GKE rota automáticamente estos certificados antes de que venzan.

Rotación de certificados

Para rotar todos los certificados de servidor y la API de tu clúster, realiza una rotación de credencial. No hay forma de activar una rotación de los certificados de etcd, esto lo administrar tú en GKE.

¿Qué sigue?