Confianza del clúster

Esta página describe la confianza en los clústeres de Google Kubernetes Engine, incluida la forma en que las instancias principales 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 instancia principal a nodo
La instancia principal se comunica con un nodo para gestionar contenedores. Cuando la instancia principal envía una solicitud al nodo, por ejemplo, a los registros de Kubectl, esa solicitud se envía a través de un túnel SSH y, además, se protege con TLS no autenticado, lo que proporciona integridad y encriptación. Cuando un nodo envía una solicitud a la instancia principal, por ejemplo, de kubelet al servidor API, esa solicitud se autentica y encripta con TLS mutuo.
De nodo a nodo
Un nodo puede comunicarse con otro nodo como parte de una carga de trabajo específica. Cuando el nodo envía una solicitud a otro nodo, esa solicitud se autentica y se encripta si esa conexión cruza un límite físico controlado por Google. Ten en cuenta que ningún componente de Kubernetes requiere comunicación de nodo a nodo. Para obtener más información, consulta el Informe técnico de encriptación en Transit.
De pod a pod
Un pod puede comunicarse con otro pod como parte de una carga de trabajo específica. Cuando el pod envía una solicitud a otro pod, esa solicitud no está autenticada ni encriptada. Ten en cuenta que ningún componente de Kubernetes requiere comunicación de pod a pod. El tráfico de pod a pod se puede restringir con una Política de red, y se puede encriptar usando una malla de servicios como Istio o implementando la encriptación de la capa de 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 encripta con TLS mutuo. El tráfico nunca deja una red propiedad de GKE protegida por firewalls.
De instancia principal a etcd
Esta comunicación es completamente a través de localhost y no está autenticada o encriptada.

Raíz de confianza

GKE se configura de tal manera que:

  • La Autoridad certificada de raíz del clúster (CA) se usa para validar el servidor de API y los certificados de cliente de Kubelets. Es decir, las instancias principales 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 mediante la API de certificates.k8s.io, mediante el envío de una solicitud de firma de certificador.
  • Se usa una CA separada por clúster para validar los certificados de etcd.

Servidor API y kubelets

El servidor API y kubelets confían en la CA de raíz del clúster de Kubernetes para obtener confianza. En GKE, el certificado de la API de la instancia principal está firmado por la CA de raíz del clúster. Cada clúster ejecuta su propia CA, de modo que si se comprometiera la CA de un clúster, ninguna otra CA del clúster se vería 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 secreto 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. Ten en cuenta que los pods pueden acceder a este secreto compartido, a menos que esté habilitado el ocultamiento de metadatos.

El servidor API y los certificados de kubelet son válidos durante cinco años, pero se pueden rotar manualmente antes cuando realizas una rotación de credenciales.

etcd

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

Las claves de raíz para la CA de etcd se distribuyen a los metadatos de cada VM en la que se ejecuta la instancia principal. Cualquier código que se ejecute en máquinas virtuales instancias principales, o con 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.

Cómo rotar 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?

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...