Los clústeres de Google Kubernetes Engine (GKE) se pueden configurar de diferentes formas que hacen que el acceso al plano de control, su maestro de Kubernetes o el servidor de API, sea una tarea no trivial. Verás que no es solo donde está el maestro, sino también donde estás tú. Exploraré los diferentes escenarios y configuraciones para ayudarlo a decidir su modelo de acceso y solucionar problemas de configuración.
Escenarios
Debes usar herramientas como kubectl para acceder a la API de Kubernetes y administrar las cargas de trabajo de tu clúster, y la forma en que tu clúster de GKE está configurado impone restricciones de acceso. Primero, veamos los diferentes lugares desde donde es posible que desees acceder a un maestro de GKE. La siguiente figura los muestra.
- Internet : esto representa acceder al maestro desde una IP pública (no GCP), por ejemplo, su computadora portátil en casa, aunque también podría ser su máquina corporativa cuando se conecta a Internet.
- Nodos de clúster : estos son sus nodos trabajadores que acceden al maestro, generalmente el agente de kubelet que se ejecuta en cada nodo.
- VM en la VPC del clúster : otras VM en la red de VPC del mismo clúster, por ejemplo, un host de administración para llegar a un extremo de API privado. Esta opción tiene más subescenarios que pueden ser relevantes en algunos casos, por ejemplo, si consideramos la subred o región donde se encuentran las VM. Profundizaré en estos más adelante.
- VM en otra VPC : similar al punto anterior pero cuando está en una VPC diferente a la del clúster. Estas VPC no están conectadas entre sí.
- Cloud Shell : este es el entorno de shell en línea para Google Cloud al que accede con su navegador, con herramientas preinstaladas como gcloud y kubectl.
- En las instalaciones : las empresas suelen conectar su espacio de IP privado a las VPC de GCP a través de una VPN o un enlace de interconexión . Este caso puede ser su máquina corporativa o herramientas de CI / CD que administran su clúster.
Ahora, expliquemos las diferentes configuraciones de GKE y cómo puede obtener acceso o no desde estos lugares.
Clústeres públicos
De forma predeterminada, los clústeres de GKE se crean con IP públicas para los nodos maestro y trabajador. Cree un clúster y recupere las credenciales de Kubernetes para obtener acceso:
Los clústeres de contenedores de $ gcloud crean un clúster de prueba
$ gcloud container clusters get-credentials test-cluster
Ejecute un comando kubectl para verificar que tiene acceso:
$ kubectl obtener nodos -o nombre
node / gke-test-cluster-default-pool-f89318a3-5bg5
node / gke-test-cluster-default-pool-f89318a3-nfsp
node / gke-test-cluster-default-pool-f89318a3-rwb1
También puede verificar el punto final de la API pública donde el maestro está escuchando:
$ kubectl cluster-info
El maestro de Kubernetes se ejecuta en https://104.155.43.13
...
Suponiendo que tenga las credenciales necesarias, tendrá acceso desde la mayoría de los entornos ya que el punto final de la API es público:
- Internet: ️️ ️✅
Es posible que ya lo sepa ya que probablemente ejecute esta prueba desde su computadora portátil. - Nodos de clúster: ️✅️
Claro, los nodos del clúster tienen IP públicas y necesitan acceso al maestro. - VM en la VPC del clúster: ✅
Cualquier VM con una IP pública puede acceder al clúster. - VM en otra VPC: ✅
El mismo comentario que el anterior, la VPC aquí no hace ninguna diferencia. - Cloud Shell: ✅
Un Cloud Shell es solo una VM administrada con una IP pública. - En las instalaciones: ❌️
Este es el único caso sin acceso al clúster. Recuerde que aquí consideramos máquinas corporativas con solo acceso privado a GCP, una máquina corporativa con IP pública sería la opción 1 (Internet).
Los clústeres públicos facilitan la administración. La API maestra es de acceso público a través de TLS, siempre que tenga las credenciales, y puede fortalecer los nodos trabajadores con las reglas de firewall de GCP.
Clústeres públicos + Redes autorizadas
Es posible que desee restringir el acceso a la API maestra a un conjunto conocido de direcciones IP, para limitar los posibles ataques o el acceso, por ejemplo, en caso de robo de credenciales. Actualice su clúster con la función de redes autorizadas de GKE y los rangos de CIDR que desee (p. Ej., La IP proporcionada por su ISP):
$ gcloud container clusters update test-cluster --enable-master-allowed-networks --master-allowed-networks cidr1, cidr2 ...
Tenga en cuenta que esto solo bloqueará las direcciones IP externas a Google. Las direcciones IP de Google Cloud seguirán teniendo acceso.
Vamos a resumirlo. El símbolo ❓ ️ significa que solo los rangos de IP autorizados tendrán acceso:
- Internet: ️️ ❓️
- Nodos de clúster: ✅️
- VM en la VPC del clúster: ️✅️
- VM en otra VPC: ️✅
- Cloud Shell: ️✅️
- En las instalaciones: ❌️
El uso de redes autorizadas con clústeres públicos realmente no agrega más seguridad, ya que un atacante potencial siempre puede activar una VM en GCP para obtener acceso desde allí.
Clústeres privados
En un clúster privado, los nodos trabajadores solo obtienen direcciones IP internas. Sin embargo, el plano de control tiene un punto final privado y un punto final público. El acceso al endpoint público se puede deshabilitar al crear un clúster privado, como veremos más adelante.
$ gcloud container clusters crean priv-cluster --enable-ip-alias --enable-private-nodes --master-ipv4-cidr 172.16.0.0/28 --no-enable-master-allowed-networks
$ gcloud container clusters get-credentials priv-cluster [--internal-ip]
El punto de conexión privado lo implementa un equilibrador de carga interno, y deberá habilitar el acceso global si desea llegar al plano de control desde una región diferente a donde se implementa:
$ gcloud container clusters actualiza priv-cluster --enable-master-global-access
Con un punto final público y privado, puede obtener acceso desde cualquier lugar, con algunas advertencias:
- Internet: ️️ ️✅
- Nodos de clúster: ️✅️
Utilizarán el punto final privado. - VM en la VPC del clúster:
◾Punto final público: ✅️
◾Punto final privado:
🔸️VM en la misma región que el clúster: ✅
🔸️VM en diferentes regiones: ️️️❌️
🔸️VM en diferentes regiones, acceso global: ✅️ - VM en otra VPC: ✅
- Cloud Shell: ✅
- En las instalaciones:
Similar a la opción 3:
🔸️VPN en la misma región que el clúster: ✅
🔸️VPN en diferentes regiones: ️️️❌️
🔸️VPN en diferentes regiones, acceso global: ✅
Los clústeres privados agregan flexibilidad para administrar desde las instalaciones, y los nodos y pods están aislados de Internet de forma predeterminada. Puede utilizar Cloud NAT para proporcionar acceso a Internet para sus nodos privados.
Clústeres privados + Redes autorizadas
Al igual que con los clústeres públicos, puedes usar la función de redes autorizadas de GKE con clústeres privados para restringir el acceso a la API maestra. Sin embargo, el comportamiento es un poco diferente:
$ gcloud container clusters crean priv-cluster --enable-ip-alias --enable-private-nodes --master-ipv4-cidr 172.16.0.0/28 --enable-master-allowed-networks --master-allowed-networks cidr1, cidr2 ...
Mientras que para los clústeres públicos solo se bloquean las direcciones IP externas a Google, para los clústeres privados todo, excepto la subred del clúster, está bloqueado con redes autorizadas.
- Internet: ️️️ ❓️
- Nodos de clúster: ️✅️
- VM en la VPC del clúster:
◾Punto final público: ❓️
◾Punto final privado:
🔸️VM en la misma región y subred que el clúster: ✅
🔸️VM en la misma región y subred diferente: ❓
🔸️VM en diferentes regiones: ️️️❌️
🔸️VM en diferentes regiones, acceso global: ❓ - VM en otra VPC: ❓
- Cloud Shell: ❓
- En las instalaciones:
🔸️VPN en la misma región que el clúster: ❓
🔸️VPN en diferentes regiones: ️️️❌️
🔸️VPN en diferentes regiones, acceso global: ❓
Con clústeres privados y redes autorizadas, obtiene más control de acceso a su clúster y mejora la seguridad mediante listas de control de acceso.
Clústeres privados + punto final privado
Como se mencionó anteriormente, el acceso al punto final público se puede deshabilitar. En este caso, se requiere la función de redes autorizadas:
$ gcloud container clusters crean priv-cluster --enable-ip-alias --enable-private-nodes --enable-private-endpoint --master-ipv4-cidr 172.16.0.0/28 --enable-master-allowed-networks --masters-autorizadas-redes cidr1, cidr2 ...
- Internet: ️️️ ❌️️
- Nodos de clúster: ️✅️
- VM en la VPC del clúster:
◾Punto final público: ❌️️
◾Punto final privado:
🔸️VM en la misma región y subred que el clúster: ✅
🔸️VM en la misma región y subred diferente: ❓
🔸️VM en diferentes regiones: ️️️❌️
🔸️VM en diferentes regiones, acceso global: ❓ - VM en otra VPC: ❌️
- Cloud Shell: ❌️
- En las instalaciones:
🔸️VPN en la misma región que el clúster: ❓
🔸️VPN en diferentes regiones: ️️️❌️
🔸️VPN en diferentes regiones, acceso global: ❓
Si no necesita o desea evitar el acceso público a su clúster, desactive el punto final público. Esta configuración es probablemente la más segura y menos flexible.
Configuraciones con intercambio de tráfico de VPC
La red de VPC del plano de control se encuentra en un proyecto administrado por Google. Esta VPC está conectada a la VPC de su clúster con intercambio de tráfico entre redes de VPC . El intercambio de tráfico entre redes de VPC no es transitivo, si la red-b está interconectada con la red-a y la red-c, pero no están conectadas directamente, la red-a no puede comunicarse con la red-c a través del intercambio de tráfico.
Esta situación ocurre a menudo en arquitecturas de concentrador y radio que utilizan VPC Peering. Imagine que la red-a es una VPC concentradora, que proporciona servicios de red como la conexión VPN a las instalaciones, la red-b es una VPC radial que ejecuta servicios como GKE y la red-c es la red de VPC del plano de control. Desde el concentrador de red o cualquier otra red conectada a él, como local, no es posible llegar al extremo privado de GKE directamente.
En estos casos, puede implementar un host de salto en la VPC de GKE para permitir el acceso a la API de Kubernetes, pero eso da para otro artículo.
Puntos de resolución de problemas
Para cerrar este artículo, aquí hay algunos problemas comunes y sugerencias relacionados con los clústeres de GKE y su plano de control:
- GKE está integrado con OAuth, así que asegúrese de que sus usuarios o cuentas de servicio tengan las funciones de IAM adecuadas (como desarrollador de Kubernetes Engine) y alcances de acceso.
- Asegúrese de habilitar el acceso global maestro si desea llegar al punto final privado desde una región diferente a donde está implementado.
- Si está conectado a un extremo privado de GKE a través de una VPN, exporte rutas personalizadas para controlar la VPC del plano para que el tráfico de retorno del maestro pueda llegar a la fuente.
- Si sus máquinas virtuales solo tienen IP privadas, probablemente necesitará acceso privado a Google (PGA) para llegar a las API de Google Cloud. PGA está habilitado de forma predeterminada en clústeres privados.
Espero que esta información aclare cómo configurar su clúster de GKE. ¡Gracias por leer!
¿Dónde está mi maestro de GKE? se publicó originalmente en Google Cloud - Community on Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.