Acerca del aislamiento de red en GKE

Puedes personalizar el acceso a la red para el plano de control y los nodos de tu clúster de Google Kubernetes Engine (GKE) para mejorar la seguridad de la red del clúster y sus cargas de trabajo. En este documento, se explican los distintos tipos de aislamiento que puedes configurar para tu clúster, los beneficios de aislar tu red y las limitaciones que debes tener en cuenta antes de aislar tu clúster.

Para configurar niveles de aislamiento específicos para tu clúster, consulta los siguientes documentos:

Práctica recomendada:

Planifica y diseña la configuración de aislamiento de red con los arquitectos de red, los ingenieros de red, los administradores de red o algún otro equipo responsable de la definición, la implementación y el mantenimiento de la arquitectura de red de tu organización.

Tipos de acceso a la red

Los componentes de tu clúster, como el plano de control, el servidor de la API y los nodos, envían y reciben tráfico de red para diferentes propósitos. Puedes personalizar el aislamiento de tu clúster controlando uno o más de los siguientes tipos de acceso a la red:

  • Acceso al plano de control desde fuentes externas: Personaliza quién puede acceder a tu plano de control para realizar tareas como ejecutar comandos kubectl en el clúster.
  • Acceso a webhooks externos desde el servidor de la API: Personaliza si el servidor de la API de Kubernetes puede enviar tráfico directamente a servidores de webhook externos a través del plano de control.
  • Acceso a los nodos desde fuentes externas: Personaliza si los clientes externos en la Internet pública pueden acceder a tus nodos.

Acceso al plano de control desde fuentes externas

En esta sección, analizarás quién puede acceder a tu plano de control.

Cada clúster de GKE tiene un plano de control que controla las solicitudes de la API de Kubernetes. El plano de control se ejecuta en una máquina virtual (VM) que está en una red de VPC en un proyecto administrado por Google. Un clúster regional tiene varias réplicas del plano de control, cada una de las cuales se ejecuta en su propia VM. Las entidades principales, como los administradores de clústeres, usan un extremo del plano de control para acceder al clúster y realizar tareas como ejecutar comandos de kubectl o implementar cargas de trabajo. Los clientes externos usan el extremo del plano de control para acceder al clúster, y no se usa para la comunicación directa con las instancias de VM de Compute Engine que alojan las réplicas del plano de control. El plano de control tiene los siguientes tipos de extremos para acceder al clúster:

El plano de control tiene dos tipos de extremos para el acceso al clúster:

  • Extremo basado en DNS
  • Extremos basados en IP
Práctica recomendada:

Usa solo el extremo basado en DNS para acceder a tu plano de control y disfrutar de una configuración simplificada y una capa de seguridad flexible basada en políticas.

Extremo basado en DNS

El extremo basado en DNS proporciona un DNS o un nombre de dominio completamente calificado (FQDN) único e inmutable para cada plano de control del clúster. Este nombre de DNS se puede usar para acceder a tu plano de control durante todo su ciclo de vida. El nombre de DNS se resuelve en un extremo al que se puede acceder desde cualquier red a la que se pueda llegar con las APIs de Cloud de Confiance by S3NS , incluidas las redes locales o de otras nubes. Habilitar el extremo basado en DNS elimina la necesidad de un host de bastión o nodos proxy para acceder al plano de control desde otras redes de VPC o ubicaciones externas.

Para acceder al extremo del plano de control, debes configurar roles y políticas de IAM, y tokens de autenticación. Para obtener más detalles sobre los permisos exactos que se requieren, consulta Personaliza el aislamiento de tu red.

Además de las políticas y los tokens de IAM, también puedes configurar los siguientes atributos de acceso:

  • Controles basados en la dirección IP o la red con Controles del servicio de VPC: Para mejorar la seguridad del plano de control de tu clúster de GKE, los Controles del servicio de VPC agregan otra capa de seguridad de acceso. Utiliza el acceso adaptado al contexto basado en atributos como el origen de la red.

    Los Controles del servicio de VPC no admiten directamente clústeres con direcciones IP públicas para su plano de control. Sin embargo, los clústeres de GKE, incluidos los clústeres públicos y privados, obtienen protección de los Controles del servicio de VPC cuando accedes a ellos con el extremo basado en DNS.

    Configura los Controles del servicio de VPC para proteger el extremo basado en DNS de tu clúster de GKE. Para ello, incluye container.googleapis.com y kubernetesmetadata.googleapis.com en la lista de servicios restringidos de tu perímetro de servicio. Agregar estas APIs a tu perímetro de servicio habilitará los VPC-SC para todas las operaciones de la API de GKE. Esta configuración ayuda a garantizar que los perímetros de seguridad definidos rijan el acceso al plano de control.

    Si usas políticas de IAM y Controles del servicio de VPC para proteger el acceso al extremo basado en DNS, crearás un modelo de seguridad de varias capas para el plano de control del clúster. Los Controles del servicio de VPC se integran con los servicios Cloud de Confiance compatibles. Alinea la configuración de seguridad de tu clúster con los datos que alojas en otros servicios de Cloud de Confiance .

  • Private Service Connect o Cloud NAT: Para acceder al extremo basado en DNS desde clientes que no tienen acceso a Internet público De forma predeterminada, se puede acceder al extremo basado en DNS a través de las APIs disponibles en la Internet pública. Cloud de ConfiancePara obtener más información, consulta Extremo basado en DNS en la página Personaliza el aislamiento de tu red.

  • Credenciales de autenticación de Kubernetes: Para autenticarse en el extremo basado en DNS con tokens de portador de ServiceAccount de Kubernetes o certificados de cliente X.509. Estos métodos de autenticación están inhabilitados de forma predeterminada en los clústeres de GKE. Puedes habilitar estos métodos cuando configures el extremo basado en DNS para un clúster.

Extremos basados en IP

De manera opcional, también puedes configurar el acceso al plano de control con extremos basados en IP.

Terminología relacionada con clústeres y direcciones IP

  • Cloud de Confiance by S3NS direcciones IP externas:

    • Las direcciones IP externas asignadas a cualquier VM que use cualquier cliente alojado enCloud de Confiance. Cloud de Confiance es propietario de estas direcciones IP. Para obtener más información, consulta ¿Dónde puedo encontrar los rangos de IP de Compute Engine?

    • Direcciones IP externas que usan los productos de Cloud de Confiance , como Cloud Run o Cloud Run Functions. Cualquier cliente alojado en Cloud de Confiance puede crear instancias de estas direcciones IP. Cloud de Confiance es propietario de estas direcciones IP.

  • Direcciones IP reservadas por Google: Direcciones IP externas para fines de administración del clúster de GKE. Estas direcciones IP incluyen procesos administrados de GKE y otros servicios de producción de Google. Google posee estas direcciones IP.

  • Rangos de direcciones IP del clúster de GKE: Direcciones IP internas asignadas al clúster que GKE usa para los nodos, los Pods y los objetos Service del clúster.

  • Direcciones IP internas: Son las direcciones IP de la red de VPC de tu clúster. Estas direcciones IP pueden incluir la dirección IP de tu clúster, las redes locales, los rangos RFC 1918 o las direcciones IP públicas de uso privado (PUPI) que incluyen rangos que no son RFC 1918.

  • Extremo externo del clúster basado en IP: Es la dirección IP del extremo externo que GKE asigna al plano de control.

  • Dirección IP externa de la VM del plano de control: Es la dirección IP externa que se asigna a cada instancia de VM que ejecuta el plano de control y que se usa solo para el tráfico de salida del servidor de la API.

  • Extremo interno: Es la dirección IP interna que GKE asigna al plano de control.

  • Red de VPC: Es una red virtual en la que creas subredes con rangos de direcciones IP específicamente para los nodos y los Pods del clúster.

Cuando usas extremos basados en IP, tienes dos opciones:

  • Expón el plano de control en los extremos externos e internos. Esto significa que se puede acceder al extremo externo del plano de control desde una dirección IP externa y al extremo interno desde la red de VPC de tu clúster. Los nodos se comunicarán con el plano de control solo en el extremo interno.

  • Expón el plano de control solo en el extremo interno. Esto significa que los clientes en Internet no se pueden conectar al clúster y que se puede acceder al plano de control desde cualquier dirección IP de la red de VPC del clúster. Los nodos se comunicarán con el plano de control solo en el extremo interno.

    Esta es la opción más segura cuando se usan extremos basados en IP, ya que impide todo acceso a Internet al plano de control. Esta es una buena opción si tienes cargas de trabajo que, por ejemplo, requieren acceso controlado debido a las reglamentaciones de privacidad y seguridad de los datos.

En ambas opciones anteriores, puedes restringir qué direcciones IP llegan a los extremos configurando redes autorizadas. Si usas extremos basados en IP, te recomendamos que agregues al menos una red autorizada. Las redes autorizadas otorgan acceso al plano de control a un conjunto específico de direcciones IPv4 de confianza y proporcionan protección y beneficios de seguridad adicionales para tu clúster de GKE.

Práctica recomendada:

Habilita las redes autorizadas cuando uses extremos basados en IP para proteger tu clúster de GKE.

Cómo funcionan las redes autorizadas

Las redes autorizadas proporcionan un firewall basado en IP que controla el acceso al plano de control de GKE. El acceso al plano de control depende de las direcciones IP de origen. Cuando habilitas las redes autorizadas, configuras las direcciones IP para las que deseas permitir el acceso al extremo del plano de control del clúster de GKE como una lista de bloques CIDR.

En la siguiente tabla, se muestra lo siguiente:

  • Las direcciones IP predeterminadas que siempre pueden acceder al plano de control de GKE, independientemente de si habilitas las redes autorizadas.
  • Son las direcciones IP configurables que pueden acceder al plano de control cuando las permites habilitando las redes autorizadas.
Extremos del plano de control Son las direcciones IP predeterminadas que siempre pueden acceder a los extremos. Dirección IP configurable que puede acceder a los extremos después de habilitar las redes autorizadas
Extremos internos y externos habilitados
  • Direcciones IP reservadas por Google
  • Rangos de direcciones IP del clúster de GKE
  • Direcciones IP externas incluidas en la lista de entidades permitidas
  • Direcciones IP internas incluidas en la lista de entidades permitidas
  • Cloud de Confiance direcciones IP externas
Solo se habilitó el extremo interno
  • Direcciones IP reservadas por Google
  • Rangos de direcciones IP del clúster de GKE
  • Direcciones IP internas incluidas en la lista de entidades permitidas

Con una red autorizada, también puedes configurar la región desde la que una dirección IP interna puede llegar al extremo interno de tu plano de control. Puedes permitir el acceso solo desde la red de VPC del clúster o desde cualquier región de Cloud de Confiance en un entorno de VPC o local.

Limitaciones del uso de extremos basados en IP

  • Si expandes una subred que un clúster usa con redes autorizadas, debes actualizar la configuración de la red autorizada para que incluya el rango de direcciones IP expandido.
  • Si tienes clientes que se conectan desde redes con direcciones IP dinámicas, como empleados en redes domésticas, debes actualizar la lista de redes autorizadas con frecuencia para mantener el acceso al clúster.
  • Si inhabilitas el acceso al extremo externo del plano de control, no podrás interactuar con tu clúster de forma remota. Si necesitas acceder al clúster de forma remota, debes usar un host de bastión que reenvíe el tráfico de clientes al clúster. En cambio, usar un extremo basado en DNS solo requiere configurar permisos de IAM.
  • Los extremos basados en IP no se integran directamente con los Controles del servicio de VPC. Los Controles del servicio de VPC operan a nivel del perímetro de servicio para controlar el acceso y el movimiento de datos dentro de Cloud de Confiance. Recomendamos usar un extremo basado en DNS con Controles del servicio de VPC para una defensa de seguridad sólida.
  • Puedes especificar hasta 100 rangos de direcciones IP autorizadas (incluidas las direcciones IP internas y externas).

Acceso a fuentes externas desde el servidor de la API

El plano de control del clúster de GKE ejecuta los componentes del plano de control de Kubernetes, como el servidor de la API, el programador y los controladores. El plano de control se ejecuta en una instancia de VM de Compute Engine que pertenece a GKE en un proyecto administrado. Los clústeres regionales y los clústeres de Autopilot tienen varias réplicas del plano de control, cada una de las cuales se ejecuta en su propia instancia de VM.

De forma predeterminada, cada una de estas instancias de VM de Compute Engine tiene una dirección IP externa que se asigna directamente a la VM. Esta dirección IP solo se usa para enviar solicitudes de admisión desde el servidor de la API de Kubernetes en una instancia a los servidores de webhook de admisión que se ejecutan fuera del clúster, por ejemplo, en un servicio en la nube diferente o en las instalaciones. Esta dirección IP solo se usa si los webhooks de admisión se comunican directamente con el servidor de webhook a través de la URL del servidor o la dirección IP del servidor.

Para mejorar la postura de seguridad de tu plano de control, puedes inhabilitar la dirección IP externa en las instancias de VM del plano de control. En caso de que se produzca una vulneración, los posibles atacantes no podrán usar estas direcciones IP externas para comunicarse. Puedes personalizar el tráfico de salida del servidor de la API de las siguientes maneras:

  • Sin tráfico de salida (NONE): Inhabilita la dirección IP externa de cada instancia del plano de control y enruta el tráfico de salida del servidor de la API a un agujero negro. Se bloquea todo el tráfico de salida no crítico del servidor de la API a destinos externos, incluido el tráfico a los servicios Cloud de Confiance fuera del clúster. Esta opción no afecta el tráfico crítico del sistema ni el tráfico de tus nodos.
  • Todo el tráfico de salida (VIA_CONTROL_PLANE): Conserva la dirección IP externa de cada instancia del plano de control y permite que el servidor de la API use la dirección IP para el tráfico de salida. Esta opción es la predeterminada en GKE.

Para obtener información sobre cómo personalizar tu clúster para una de estas opciones, consulta Restringe el tráfico de salida del servidor de la API.

Configuración de webhook externo

Cuando configuras las restricciones de salida del plano de control en NONE, el servidor de la API no puede realizar ninguna llamada directa a direcciones IP externas ni a nombres de dominio completamente calificados (FQDN). El parámetro de configuración NONE tiene los siguientes efectos en los webhooks externos:

  • En la versión 1.35.1-gke.1396000 y posteriores, GKE impide la creación o actualización de ValidatingWebhookConfigurations o MutatingWebhookConfigurations que usan el campo clientConfig.url.
  • Las configuraciones de webhook existentes que usan el campo clientConfig.url para comunicarse con un servidor externo dejan de funcionar.

Para crear y usar servidores de webhook externos, debes hacer lo siguiente:

  1. Actualiza tus objetos ValidatingWebhookConfigurations o MutatingWebhookConfigurations para usar el campo clientConfig.service. Este campo permite que el servidor de la API envíe solicitudes a un extremo de Service, como my-webhook.default.svc, en tu clúster. Estas solicitudes no se bloquean porque el tráfico está dentro del clúster. Para obtener más información, consulta la referencia del servicio.

  2. Configura el servicio para enrutar el tráfico a tu servidor de webhook externo. Puedes usar uno de los siguientes diseños de enrutamiento del tráfico, según tus requisitos operativos y de seguridad:

    • Pods de proxy: Usa un Deployment o un StatefulSet como backend para tu servicio. Configura los Pods para que funcionen como proxies que redireccionen las solicitudes de admisión entrantes a tu servidor de webhook externo. Este diseño te permite realizar tareas adicionales, como inspeccionar y modificar las solicitudes de admisión.
    • EndpointSlices: Crea el Service sin un selector y, luego, agrega manualmente un EndpointSlice que asigne el Service a la dirección IP del servidor externo de webhook. Este diseño enruta el tráfico sin modificar las solicitudes.

Cuando diseñes la configuración de tu webhook, ten en cuenta los siguientes factores:

  • Autenticación y credenciales: Considera cómo autenticarte con el servidor externo de webhook. Tu flujo de trabajo de enrutamiento de tráfico también debe administrar cómo se aplican las credenciales (como las claves de API, los certificados de mTLS y los tokens de OAuth) a las conexiones.
  • Control de seguridad y red: Considera la superficie de ataque de tu diseño de enrutamiento y tus opciones de seguridad y auditoría. El diseño que implementes afectará las restricciones que puedes aplicar al tráfico. Por ejemplo, puedes usar NetworkPolicies con Pods de proxy.
  • Observabilidad y confiabilidad: Considera cómo supervisar las conexiones. Por ejemplo, puedes configurar Pods de proxy para que emitan métricas o implementar la observabilidad de la red para EndpointSlices.

Acceso a los nodos desde fuentes externas

En esta sección, se analiza el aislamiento de nodos dentro de un clúster de Kubernetes.

Habilitar nodos privados

Impedir que los clientes externos accedan a los nodos aprovisionándolos solo con direcciones IP internas, lo que los convierte en nodos privados Las cargas de trabajo que se ejecutan en nodos sin una dirección IP externa no pueden acceder a Internet, a menos que se habilite la NAT en la red del clúster. Puedes cambiar estos parámetros de configuración en cualquier momento.

Puedes habilitar nodos privados a nivel de clúster individual o a nivel del grupo de nodos (para Standard) o de la carga de trabajo (para Autopilot). Habilitar nodos privados a nivel del grupo de nodos o de la carga de trabajo anula cualquier configuración de nodos a nivel del clúster.

Si actualizas un grupo de nodos público al modo privado, es posible que las cargas de trabajo que requieren acceso fuera de la red del clúster fallen en las siguientes situaciones:

  • Clústeres en una red de VPC compartida en la que no está habilitado el Acceso privado a Google. Habilita manualmente el Acceso privado a Google para asegurarte de que GKE descargue la imagen del nodo asignada. En el caso de los clústeres que no se encuentran en una red de VPC compartida, GKE habilita automáticamente el Acceso privado a Google.

  • Cargas de trabajo que requieren acceso a Internet en las que Cloud NAT no está habilitado o no se define una solución de NAT personalizada. Para permitir el tráfico de salida a Internet, habilita Cloud NAT o una solución NAT personalizada.

Ya sea que habilites o no los nodos privados, el plano de control aún se comunica con todos los nodos solo a través de direcciones IP internas.

Beneficios del aislamiento de red

Estos son los beneficios del aislamiento de red:

  • Flexibilidad:

    • Los clústeres tienen una configuración unificada y flexible. Los clústeres con o sin extremos externos comparten la misma arquitectura y admiten la misma funcionalidad. Puedes proteger el acceso según los controles y las prácticas recomendadas que satisfagan tus necesidades. Toda la comunicación entre los nodos de tu clúster y el plano de control usa una dirección IP interna.
    • Puedes cambiar la configuración del acceso al plano de control y de los nodos del clúster en cualquier momento sin tener que volver a crear el clúster.
    • Puedes habilitar el extremo externo del plano de control si necesitas administrar tu clúster desde cualquier ubicación con acceso a Internet o desde redes o dispositivos que no estén conectados directamente a tu VPC. También puedes inhabilitar el extremo externo para mejorar la seguridad si necesitas mantener el aislamiento de la red para cargas de trabajo sensibles. En cualquier caso, puedes usar redes autorizadas para limitar el acceso a rangos de IP de confianza.

  • Seguridad:

    • Los extremos basados en DNS con Controles del servicio de VPC proporcionan un modelo de seguridad de varias capas que protege tu clúster contra redes no autorizadas y contra identidades no autorizadas que acceden al plano de control. Los Controles del servicio de VPC se integran con los Registros de auditoría de Cloud para supervisar el acceso al plano de control.
    • No se puede acceder directamente a los nodos privados ni a las cargas de trabajo que se ejecutan en ellos desde Internet pública, lo que reduce significativamente la posibilidad de ataques externos a tu clúster.
    • Puedes bloquear el acceso al plano de control desde Cloud de Confiance direcciones IP externas o desde direcciones IP externas para aislar por completo el plano de control del clúster y reducir la exposición a posibles amenazas de seguridad.
    • Puedes inhabilitar las direcciones IP externas de las instancias de VM del plano de control para evitar que los atacantes las usen.

  • Cumplimiento: Si trabajas en una industria con reglamentaciones estrictas para el acceso y el almacenamiento de datos, los nodos privados ayudan con el cumplimiento, ya que garantizan que los datos sensibles permanezcan dentro de tu red privada.

  • Control: Los nodos privados te brindan un control detallado sobre cómo fluye el tráfico dentro y fuera de tu clúster. Puedes configurar reglas de firewall y políticas de red para permitir solo la comunicación autorizada. Si trabajas en entornos de múltiples nubes, los nodos privados pueden ayudarte a establecer una comunicación segura y controlada entre diferentes entornos.

  • Costo: Si habilitas nodos privados, puedes reducir los costos de los nodos que no requieren una dirección IP externa para acceder a los servicios públicos en Internet.

¿Qué sigue?