En esta página se describe el modelo de confianza de los clústeres de Google Kubernetes Engine (GKE), incluida la comunicación dentro de los clústeres y cómo se autentican las solicitudes de componentes como los planos de control.
Este documento está dirigido a especialistas en seguridad que quieran conocer el modelo de confianza de los clústeres de GKE. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud
Antes de leer esta página, asegúrese de que conoce los siguientes conceptos:
Comunicación entre clústeres
GKE aplica varios mecanismos de seguridad al tráfico entre los componentes del clúster, como se indica a continuación:
Tráfico entre el plano de control y los nodos: el plano de control se comunica con un nodo para gestionar los 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 proxy de Konnectivity. Las solicitudes que envía el plano de control están autenticadas y protegidas por TLS. Cuando un nodo envía una solicitud al plano de control (por ejemplo, del kubelet al servidor de la API), esa solicitud se autentica y se cifra mediante TLS mutuo (mTLS).Todos los clústeres creados y actualizados recientemente usan TLS 1.3 para la comunicación entre el plano de control y los nodos. TLS 1.2 es la versión mínima admitida para la comunicación entre el plano de control y los nodos.
Tráfico entre nodos: los nodos son máquinas virtuales de Compute Engine. Las conexiones entre los nodos de la red de producción Google Cloud están autenticadas y encriptadas. Para obtener más información, consulta la sección de VM a VM del informe sobre el cifrado 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 cifra el tráfico entre pods de diferentes nodos en la capa de red. El tráfico entre pods del mismo nodo no se cifra de forma predeterminada. Para obtener más información sobre el cifrado de la capa de red, consulta Google Cloud Cifrado y autenticación de redes virtuales.
Puedes restringir el tráfico de pod a pod con una NetworkPolicy y cifrar todo el tráfico de pod a pod, incluido el tráfico del mismo nodo, mediante una malla de servicios como Cloud Service Mesh u otro método de cifrado de capa de aplicación.
Tráfico entre componentes del plano de control: el tráfico entre los distintos componentes que se ejecutan en el plano de control se autentica y se cifra mediante TLS. El tráfico nunca sale de una red propiedad de Google protegida por firewalls.
Raíz de confianza
GKE tiene la siguiente configuración:
- La autoridad de certificación (CA) raíz del clúster se usa para validar los certificados de cliente del servidor de la API y de los kubelets. Es decir, los planos de control y los nodos tienen la misma raíz de confianza. Cualquier kubelet del grupo de nodos del clúster puede solicitar un certificado de esta AC mediante la API
certificates.k8s.io. Para ello, debe enviar una solicitud de firma de certificado. La CA raíz tiene un tiempo de vida limitado, tal como se describe en la sección Tiempo 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 peer de etcd por clúster para establecer la confianza entre las instancias de etcd.
- En todos los clústeres de GKE, se usa una AC de API de etcd independiente para establecer la confianza entre el servidor de la API de Kubernetes y la API de etcd.
Servidor de la API y kubelets
El servidor de la API y los kubelets dependen de la CA raíz del clúster para establecer la confianza. En GKE, el certificado de la API del plano de control está firmado por la AC raíz del clúster. Cada clúster ejecuta su propia CA, de modo que, si se vulnera la CA de un clúster, no se vea afectada la CA de ningún otro clúster.
Un servicio interno gestiona las claves raíz de esta CA, que no se pueden exportar. Este servicio acepta solicitudes de firma de certificados, incluidas las de los kubelets de cada clúster de GKE. Aunque se viera comprometido el servidor de la API de un clúster, la autoridad de certificación no se vería afectada, por lo que no se verían afectados otros clústeres.
En cada nodo del clúster se inserta un secreto compartido en el momento de la creación, que puede usar para enviar solicitudes de firma de certificado a la AC raíz del clúster y obtener certificados de cliente de kubelet. El kubelet usa estos certificados para autenticar sus solicitudes al servidor de la API. Los pods del nodo pueden acceder a este secreto compartido, a menos que habilites nodos de GKE blindados o Workload Identity Federation para GKE.
Tiempo de validez de la AC raíz del clúster
La AC raíz del clúster tiene una vida útil limitada, tras la cual no serán válidos los certificados firmados por la AC caducada. Para consultar la fecha de vencimiento aproximada de la CA de tu clúster, sigue las instrucciones que se indican en Comprobar la duración de las credenciales.
Debes rotar manualmente tus credenciales antes de que caduque tu AC raíz. Si la CA caduca y no rotas tus credenciales, es posible que tu clúster entre en un estado irrecuperable. GKE cuenta con los siguientes mecanismos para intentar evitar que los clústeres no se puedan recuperar:
- Tu clúster entra en el estado
DEGRADEDsiete días antes de que caduque la CA GKE intenta rotar las credenciales automáticamente 30 días antes de que caduque la CA. Esta rotación automática ignora las ventanas de mantenimiento y puede provocar interrupciones, ya que GKE vuelve a crear nodos para usar las nuevas credenciales. Los clientes externos, como kubectl en entornos locales, no funcionarán hasta que los actualices para que usen las nuevas credenciales.
Para saber cómo realizar una rotación, consulta Rotar 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 de tu plano de control interactúa con esta base de datos mediante la API 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 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, todos los clústeres de GKE sirven la API de etcd en el plano de control. Para cifrar el tráfico que implica la base de datos de estado del clúster, GKE usa una o ambas de las siguientes CAs por clúster:
- AC de la API de etcd: se usa para firmar certificados del tráfico hacia y desde los endpoints de la API de etcd. En cada clúster de GKE se ejecuta una CA de la API etcd.
- AC de peer de etcd: se usa para firmar certificados para el tráfico entre instancias de la base de datos etcd en el plano de control. Una CA de peer de etcd se ejecuta en cualquier clúster que use bases de datos etcd. Los clústeres que usan bases de datos de Spanner no usan la autoridad de certificación de pares de etcd.
Las claves raíz de la CA de la API etcd se distribuyen a los metadatos de cada instancia de Compute Engine en la que se ejecuta el plano de control. La API etcd CA no se comparte entre clústeres.
Los certificados de AC de etcd tienen una validez de cinco años. GKE rota automáticamente estos certificados antes de que caduquen.
Rotación de certificados
Para rotar todos los certificados del servidor de la API y de kubelet de tu clúster, realiza una rotación de credenciales. No puedes activar la rotación de los certificados etcd, ya que GKE se encarga de gestionarlos.