Confianza del clúster

En esta página, se describe la confianza en los clústeres de Google Kubernetes Engine (GKE), incluida la forma en que los planos de control y los nodos autentican las solicitudes.

Comunicación intraclúster

En un clúster hay muchas conexiones para la comunicación entre los componentes de Kubernetes.

De plano de control a nodo

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 de los clústeres públicos, la solicitud se envía a través de un túnel de proxy de Konnectivity. Las solicitudes a nodos de clústeres privados se envían a través del intercambio de tráfico de VPC. Las solicitudes enviadas por el plano de control están protegidas con TLS, lo que proporciona autenticación, integridad y encriptación. Cuando un nodo envía una solicitud al plano de control, por ejemplo, desde el kubelet al servidor API, esa solicitud se autentica y encripta mediante TLS mutuo.

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.

De nodo a nodo

Los nodos son VMs de Compute Engine para las que se autentican y encriptan las conexiones dentro de la red de producción de Google Cloud. Para obtener más información, consulta la sección de VM a VM del -Informe de encriptación en tránsito.

De pod a pod

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 de 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 Encriptación y autenticación de la red virtual de Google Cloud.

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, mediante una malla de servicios comoCloud Service Mesh o con un método diferente de encriptación de la capa de la aplicación.

De etcd a etcd

Una instancia de etcd puede comunicarse con otra instancia de etcd para mantener el estado actualizado. Cuando una instancia de etcd envía una solicitud a otra instancia, esa solicitud se autentica y se encripta con la TLS mutua. El tráfico nunca deja una red propiedad de GKE protegida por firewalls.

De plano de control a etcd

Esta comunicación se encripta con TLS mutua.

Raíz de confianza

GKE tiene la siguiente configuración:

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 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 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 mediante 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.

etcd

En GKE, etcd confía en una CA de etcd separada por clúster para obtener confianza.

Las claves de raíz para la CA de etcd se distribuyen a los metadatos de cada máquina virtual (VM) en la que se ejecuta el plano de control. Cualquier código que se ejecute en las VM de plano de control o que tenga acceso a metadatos de procesamiento para estas VM, puede firmar certificados como esta CA. Incluso si se comprometiera el etcd en un clúster, la CA no se comparte entre clústeres, por lo que otros clústeres no se verían afectados.

Los certificados etcd son válidos por cinco años.

Rota tus 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?