Confianza del clúster

En esta página, se describe la confianza en los clústeres de Google Kubernetes Engine, incluida la forma en que los planos de control (instancia principal) 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.

Plano de control al nodo

El plano de control se comunica con un nodo para administrar contenedores. Cuando este 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 de forma más segura, lo que proporciona autenticación, integridad y encriptación. Cuando un nodo envía una solicitud al plano de control, por ejemplo, de kubelet al servidor API, esa solicitud se autentica y encripta con TLS mutua.

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

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 con una malla de servicios como Istio o si implementas 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 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 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, 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.
  • Se usa una CA de etcd 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 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 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 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.

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?