Prácticas recomendadas para usar pasarelas de salida de Cloud Service Mesh en clústeres de GKE

En este documento se describe cómo usar las pasarelas de salida de Cloud Service Mesh y otros Google Cloud controles para proteger el tráfico saliente de las cargas de trabajo desplegadas en un clúster de Google Kubernetes Engine (GKE). Estos controles pueden limitar las conexiones a servicios externos en función de la identidad de la aplicación de origen, el espacio de nombres de un equipo, el dominio de destino y otras propiedades de las solicitudes salientes.

Este documento está dirigido a ingenieros de redes, plataformas y seguridad que administran clústeres de GKE utilizados por uno o varios equipos de lanzamiento de software. Los controles que se describen en este artículo pueden ser especialmente útiles para las organizaciones que deben demostrar el cumplimiento de las normativas (por ejemplo, el RGPD y el PCI).

Introducción

El enfoque tradicional de la seguridad de redes ha consistido en definir perímetros de seguridad en torno a un grupo de aplicaciones. Los firewalls se usan en estos perímetros para permitir o denegar el tráfico en función de las direcciones IP de origen y destino, al tiempo que se confía en las aplicaciones y el tráfico contenidos en el perímetro. Sin embargo, esta confianza implica un riesgo. Un insider malicioso o cualquier persona que vulnere el perímetro puede moverse libremente por la red, acceder a los datos y extraerlos, atacar sistemas de terceros e interferir en los sistemas de administración.

Cuando las cargas de trabajo que se ejecutan en un clúster de Kubernetes establecen conexiones de salida con hosts en Internet, aplicar controles de seguridad tradicionales basados en IP puede ser complicado por los siguientes motivos:

  • Las direcciones IP de los pods no representan adecuadamente la identidad de la carga de trabajo que realiza la conexión. En un entorno de Kubernetes, las direcciones IP de los pods se asignan de forma efímera y se reciclan con frecuencia a medida que los pods se crean y se eliminan.

  • A menudo es imposible identificar un conjunto pequeño y fijo de direcciones IP para hosts de destino concretos. Las direcciones IP cambian con frecuencia, varían según la región y pueden proceder de intervalos grandes o representar cachés, proxies o CDNs.

  • Es posible que varios equipos que compartan el mismo clúster multiinquilino, con un intervalo compartido de IPs de origen, tengan requisitos de conectividad externa diferentes.

Cloud Service Mesh es una malla de servicios totalmente gestionada en Google Cloud basada en la malla de servicios Istio de código abierto. Una malla de servicios proporciona una forma uniforme de conectar, gestionar y proteger la comunicación de las aplicaciones. Las mallas de servicios adoptan un enfoque centrado en las aplicaciones y usan identidades de aplicaciones de confianza en lugar de un enfoque centrado en la IP de la red.

Puede implementar una malla de servicios de forma transparente sin necesidad de modificar el código de aplicación. El uso de una malla de servicios ayuda a separar el trabajo de los equipos de desarrollo responsables de ofrecer y lanzar funciones de aplicaciones de las responsabilidades de los administradores de redes, ya que proporciona un control declarativo del comportamiento de la red.

Cloud Service Mesh ofrece la opción de desplegar proxies de reenvío independientes,conocidos como pasarelas de salida, en el perímetro de la malla. En esta guía se explica cómo se pueden combinar las funciones del proxy de pasarela de salida con las funciones de Google Cloud para controlar, autorizar y observar el tráfico saliente de las cargas de trabajo implementadas en un clúster de GKE.

componentes conceptuales

Arquitectura de defensa en profundidad

En el diagrama siguiente se muestra una arquitectura que adopta un enfoque de defensa en profundidad para controlar con precisión el tráfico de salida de un clúster utilizado por varios equipos. Los controles se basan en los controles de red de la capa 4 (transporte) y la capa 7 (aplicación).

Arquitectura general

La arquitectura usa los siguientes recursos y controles:

  • Un clúster de GKE privado: los nodos de un clúster de GKE privado solo tienen direcciones IP internas y no están conectados a Internet de forma predeterminada.

  • Cloud NAT: Cloud NAT permite el acceso saliente a Internet desde el clúster privado.

  • Reglas de cortafuegos de la nube privada virtual (VPC): configura reglas de cortafuegos de la VPC para aplicar controles de capa 4 (Transporte) a las conexiones con los nodos del clúster de GKE. Puedes aplicar reglas de cortafuegos de VPC a las VMs en función de las cuentas de servicio o las etiquetas de red.

  • Grupos de nodos de GKE con diferentes cuentas de servicio: te permite configurar diferentes reglas de firewall que se apliquen en función del grupo de nodos al que pertenezca un nodo.

  • Espacios de nombres de Kubernetes: crea espacios de nombres para cada equipo con el fin de proporcionar aislamiento y control administrativo delegado. Los administradores de redes usan un espacio de nombres específico para desplegar la pasarela de salida y configurar el enrutamiento a hosts externos.

  • Políticas de red de Kubernetes: las políticas de red te permiten aplicar controles de capa 4 a los pods. Cada política de red se limita a un espacio de nombres y se puede acotar aún más a determinados pods de un espacio de nombres.

  • Una pasarela de salida: el tráfico que sale de los pods de la malla se dirige a través de proxies de pasarela de salida dedicados que se ejecutan en nodos dedicados. Implementas pasarelas de salida con una herramienta de adaptación dinámica horizontal de pods para que el número de réplicas aumente y disminuya en función del tráfico.

  • Políticas de autorización: utiliza políticas de autorización de la malla para aplicar controles de capa 7 (aplicación) al tráfico entre pods de la malla y al tráfico que sale de la malla.

  • Recursos de Sidecar: los recursos de Sidecar se usan para controlar el ámbito de configuración de los proxies de Sidecar que se ejecutan en cada pod de carga de trabajo. Puedes usar el recurso Sidecar para configurar los espacios de nombres, los pods y los servicios externos que son visibles para una carga de trabajo.

  • Acceso privado a Google: esta opción permite que los nodos y los pods del clúster privado accedan a las APIs de Google y extraigan imágenes Docker de Container Registry.

  • Workload Identity de GKE: con Workload Identity, puedes usar Gestión de Identidades y Accesos (IAM) para conceder permisos de API a cargas de trabajo específicas siguiendo el principio de mínimos accesos, sin necesidad de gestionar secretos.

Configurar controles de salida

Si usas la pasarela de salida para proteger el tráfico de salida de tu malla, te recomendamos que configures los controles de defensa en profundidad que se describen en esta sección.

Usar GKE privado con Cloud NAT

Cuando la seguridad es importante, el primer requisito de muchas organizaciones es evitar asignar direcciones IP públicas a sus cargas de trabajo. Un clúster de GKE privado cumple este requisito. Puedes configurar el modo VPC nativo en tu clúster privado para que se asignen direcciones IP a los pods y servicios desde rangos secundarios de la VPC. Las direcciones IP de los pods nativas de VPC se pueden enrutar de forma nativa en la red de VPC.

Es posible que algunas cargas de trabajo necesiten acceder a servicios fuera de la red de VPC y a Internet. Para permitir que las cargas de trabajo se conecten a hosts externos sin necesidad de que tengan direcciones IP públicas, configura Cloud NAT para que proporcione traducción de direcciones de red (NAT).

Asegúrate de que Cloud NAT esté configurado de forma que la pasarela de salida pueda establecer un número suficiente de conexiones simultáneas con destinos externos. Puedes evitar el agotamiento de puertos y los problemas con los retrasos en la reutilización de conexiones si defines el número mínimo de puertos por VM de forma adecuada. Consulta más información en el artículo sobre direcciones y puertos de Cloud NAT. Aumentar el número de réplicas de la puerta de enlace de salida puede ayudar a reducir las probabilidades de que se produzcan conflictos de asignación independiente de puntos finales.

Configurar Acceso privado de Google para APIs y servicios de Google

Es probable que tus cargas de trabajo necesiten acceder a las APIs y los servicios de Google. Usa el acceso privado de Google con zonas DNS personalizadas para permitir la conectividad de subredes de VPC privadas a las APIs de Google mediante un conjunto de cuatro direcciones IP. Cuando se usan estas direcciones IP, los pods no necesitan tener direcciones IP externas y el tráfico nunca sale de la red de Google. Puedes usar private.googleapis.com (199.36.153.8/30) o restricted.googleapis.com (199.36.153.4/30), según si usas Controles de Servicio de VPC.

Usar Workload Identity y gestión de identidades y accesos para proteger aún más las APIs y los servicios de Google

Se recomienda usar Workload Identity para permitir que las cargas de trabajo de GKE se autentiquen con las APIs de Google y que los administradores apliquen controles de autorización con mínimos accesos mediante IAM.

Cuando se usan las funciones de acceso privado a Google, identidad de carga de trabajo y gestión de identidades y accesos, puedes permitir de forma segura que los pods de carga de trabajo omitan la pasarela de salida y se conecten directamente a las APIs y los servicios de Google.

Usar espacios de nombres de Kubernetes para el control administrativo

Los espacios de nombres son un recurso organizativo útil en entornos con muchos usuarios, equipos o arrendatarios. Se pueden considerar como un clúster virtual y permiten delegar la responsabilidad administrativa de grupos de recursos de Kubernetes en diferentes administradores.

Los espacios de nombres son una función importante para aislar el control administrativo. Sin embargo, de forma predeterminada, no proporcionan aislamiento de nodos, aislamiento de plano de datos ni aislamiento de red.

Cloud Service Mesh se basa en los espacios de nombres de Kubernetes y los usa como unidad de arrendamiento en una malla de servicios. Las políticas de autorización de la malla y los recursos de sidecar pueden restringir la visibilidad y el acceso en función del espacio de nombres, la identidad y los atributos de la capa 7 (aplicación) del tráfico de red.

Del mismo modo, puedes usar las políticas de red de Kubernetes para permitir o denegar conexiones de red en la capa 4 (transporte).

Ejecutar pasarelas de salida en nodos de pasarela dedicados

Ejecutar pasarelas de salida en nodos de un grupo de nodos de pasarela dedicado ofrece varias ventajas. Los nodos orientados al exterior pueden usar una configuración reforzada, y puedes configurar reglas de cortafuegos de VPC para evitar que las cargas de trabajo accedan directamente a hosts externos. Los grupos de nodos se pueden autoescalar de forma independiente mediante la herramienta de adaptación dinámica del clúster.

Para permitir el control administrativo independiente de la pasarela de salida, despliégala en un espacio de nombres istio-egress específico. Sin embargo, los espacios de nombres son un recurso de todo el clúster y no se pueden usar para controlar en qué nodos se ejecuta la implementación. Para controlar la implementación, usa un selector de nodos para la implementación de la pasarela de salida, de forma que se ejecute en nodos etiquetados como miembros del grupo de nodos de la pasarela.

Asegúrate de que solo los pods de la pasarela se puedan ejecutar en los nodos de la pasarela. Otros pods deben repelerse de los nodos de la pasarela. De lo contrario, se podrían eludir los controles de salida. Puedes evitar que las cargas de trabajo se ejecuten en determinados nodos mediante intolerancias y tolerancias. Debes contaminar los nodos del grupo de nodos de la pasarela y añadir una tolerancia correspondiente a la implementación de la pasarela de salida.

Aplicar reglas de cortafuegos de VPC a nodos específicos

Configuras el enrutamiento de la malla de servicios para dirigir el tráfico de salida de las cargas de trabajo que se ejecutan en el grupo de nodos predeterminado a través de las pasarelas de salida que se ejecutan en el grupo de nodos de pasarela. Sin embargo, la configuración de enrutamiento de la malla no debe considerarse un límite de seguridad, ya que hay varias formas en las que una carga de trabajo podría eludir los proxies de la malla.

Para evitar que las cargas de trabajo de las aplicaciones se conecten directamente a hosts externos, aplica reglas de cortafuegos de salida restrictivas a los nodos del grupo de nodos predeterminado. Aplica reglas de cortafuegos independientes a los nodos de la pasarela para que los pods de la pasarela de salida que se ejecutan en ellos puedan conectarse a hosts externos.

Al crear una regla de cortafuegos de VPC, se especifican los puertos y los protocolos que la regla permite o deniega, así como la dirección del tráfico al que se aplica. Las reglas de salida se aplican al tráfico saliente y las reglas de entrada, al tráfico entrante. El valor predeterminado de salida es allow y el de entrada es deny.

Las reglas de cortafuegos se aplican en orden según un número de prioridad que puede especificar. Las reglas de cortafuegos tienen estado, lo que significa que, si se permite tráfico específico desde una VM, también se permite el tráfico de retorno que use la misma conexión.

En el siguiente diagrama se muestra cómo se pueden aplicar reglas de firewall independientes a los nodos de dos grupos de nodos diferentes en función de la cuenta de servicio asignada a un nodo. En este caso, una deny allregla de cortafuegos predeterminada deniega el acceso de salida a toda la VPC. Para evitar que se anulen las reglas de cortafuegos predeterminadas que son esenciales para que funcione tu clúster, tu regla deny all debe usar una prioridad baja, como 65535. Se aplica una regla de cortafuegos de salida aditiva y de mayor prioridad a los nodos de la pasarela para permitirles conectarse directamente a hosts externos en los puertos 80 y 443. El grupo de nodos predeterminado no tiene acceso a hosts externos.

grupo de nodos de cortafuegos

Usar políticas de red de Kubernetes como cortafuegos para pods y espacios de nombres

Usa políticas de red de Kubernetes para aplicar una capa adicional de seguridad como parte de una estrategia de defensa reforzada. Las políticas de red se limitan a los espacios de nombres y operan en la capa 4 (transporte). Con las políticas de red, puedes restringir la entrada y la salida:

  • Entre espacios de nombres
  • A pods de un espacio de nombres
  • A puertos y bloques de IP concretos.

Cuando una política de red selecciona pods en un espacio de nombres, se rechazan todas las conexiones que no se hayan permitido explícitamente. Cuando se aplican varias políticas de red, el resultado es acumulativo y es una unión de las políticas. El orden en el que se aplican las políticas no importa.

Estos son algunos ejemplos de políticas de red:

  • Permite las conexiones de salida desde los espacios de nombres de la carga de trabajo a los espacios de nombres istio-system y istio-egress. Los pods deben poder conectarse al plano de control y a la pasarela de salida.
  • Permite que las cargas de trabajo hagan consultas de DNS desde los espacios de nombres de las cargas de trabajo al puerto 53 en el espacio de nombres kube-system.
  • Opcionalmente, permite que las cargas de trabajo del mismo espacio de nombres se conecten entre sí.
  • También puedes permitir las conexiones de salida entre los espacios de nombres que usan los diferentes equipos de aplicaciones.
  • Permite las conexiones de salida desde los espacios de nombres de las cargas de trabajo a las IPs virtuales de las APIs de Google (expuestas mediante el acceso privado a Google). Cloud Service Mesh proporciona una CA gestionada y la expone como una API, por lo que los proxies sidecar deben poder conectarse a ella. También es probable que algunas cargas de trabajo necesiten acceder a las APIs de Google.
  • Permite las conexiones de salida desde los espacios de nombres de las cargas de trabajo al servidor de metadatos de GKE para que los proxies sidecar y las cargas de trabajo puedan hacer consultas de metadatos y autenticarse en las APIs de Google.

De forma predeterminada, cuando se inserta un proxy sidecar en un pod de carga de trabajo, se programan iptables reglas para que el proxy capture todo el tráfico TCP de entrada y salida. Sin embargo, como se ha mencionado anteriormente, las cargas de trabajo pueden saltarse el proxy. Las reglas de cortafuegos de VPC impiden el acceso de salida directo desde los nodos predeterminados que ejecutan las cargas de trabajo. Puedes usar políticas de red de Kubernetes para asegurarte de que no sea posible el tráfico de salida externo directo desde los espacios de nombres de las cargas de trabajo y de que sí sea posible el tráfico de salida al espacio de nombres istio-egress.

Si también controlas el tráfico de entrada con políticas de red, debes crear políticas de entrada que se correspondan con tus políticas de salida.

Configuración y seguridad de la malla de servicios

Las cargas de trabajo que se ejecutan en una malla de servicios no se identifican por sus direcciones IP. Cloud Service Mesh asigna una identidad sólida y verificable en forma de certificado y clave X.509 a cada carga de trabajo. Se establece una comunicación de confianza entre las cargas de trabajo mediante conexiones TLS mutuo (mTLS) autenticadas y cifradas.

El uso de la autenticación mTLS con una identidad bien definida para cada aplicación te permite usar políticas de autorización de la malla para controlar de forma pormenorizada cómo pueden comunicarse las cargas de trabajo con los servicios externos.

Aunque el tráfico puede salir de la malla directamente desde los proxies sidecar, si necesitas más control, te recomendamos que lo dirijas a través de las pasarelas de salida, tal como se describe en esta guía.

Gestionar la configuración de los controles de salida en un espacio de nombres dedicado

Permite a los administradores de redes gestionar los controles de forma centralizada mediante un espacio de nombres istio-egress específico para la configuración de la malla relacionada con el tráfico saliente. Como se ha recomendado anteriormente, debes implementar la pasarela de salida en el espacio de nombres istio-egress. Puedes crear y gestionar entradas de servicio, pasarelas y políticas de autorización en este espacio de nombres.

Requerir la configuración explícita de destinos externos

Asegúrate de que los proxies de malla solo estén programados con rutas a hosts externos que se hayan definido explícitamente en el registro de la malla de servicios. Define el modo de política de tráfico de salida como REGISTRY_ONLY en un recurso sidecar predeterminado para cada espacio de nombres. Configurar la política de tráfico de salida de la malla no debe considerarse por sí solo un control de perímetro seguro.

Definir destinos externos con entradas de servicio

Configura Service Entries para registrar explícitamente hosts externos en el registro de servicios de la malla. De forma predeterminada, las entradas de servicio son visibles para todos los espacios de nombres. Utilice el atributo exportTo para controlar en qué espacios de nombres se puede ver una entrada de servicio. Las entradas de servicio determinan las rutas salientes que se configuran en los proxies de malla, pero no se deben considerar por sí solas como un control seguro para determinar a qué hosts externos pueden conectarse las cargas de trabajo.

Configurar el comportamiento de la pasarela de salida con el recurso Gateway

Configura el comportamiento de balanceo de carga de las pasarelas de salida mediante el recurso Gateway. El balanceador de carga se puede configurar para un conjunto concreto de hosts, protocolos y puertos, y se puede asociar a una implementación de pasarela de salida. Por ejemplo, una pasarela se puede configurar para que salga a los puertos 80 y 443 de cualquier host externo.

En Cloud Service Mesh, mTLS automático está habilitado de forma predeterminada. Con mTLS automático, un proxy sidecar del cliente detecta automáticamente si el servidor tiene un sidecar. El sidecar del cliente envía mTLS a las cargas de trabajo con sidecars y tráfico de texto sin formato a las cargas de trabajo sin sidecars. Incluso con mTLS automático, el tráfico enviado a la pasarela de salida desde los proxies sidecar no usa automáticamente mTLS. Para indicar cómo se deben proteger las conexiones a la pasarela de salida, debe definir el modo TLS en el recurso Gateway. Siempre que sea posible, usa mTLS para las conexiones de los proxies sidecar a la pasarela de salida.

Es posible permitir que las cargas de trabajo inicien conexiones TLS (HTTPS) por sí mismas. Si las cargas de trabajo originan conexiones TLS, normalmente en el puerto 443, debes configurar la pasarela para que utilice el modo passthrough en las conexiones de ese puerto. Sin embargo, si se usa el modo passthrough, la pasarela no puede aplicar políticas de autorización basadas en la identidad de la carga de trabajo ni en las propiedades de la solicitud cifrada. Además, actualmente no se pueden usar mTLS y passthrough al mismo tiempo.

tls pass through

Configurar servicios virtuales y reglas de destino para enrutar el tráfico a través de la pasarela

Usa Virtual Services y Destination Rules para configurar el enrutamiento del tráfico de los proxies sidecar a través de la pasarela de salida a destinos externos. Los servicios virtuales definen reglas para hacer coincidir cierto tráfico. El tráfico coincidente se envía a un destino. Las reglas de destino pueden definir subconjuntos (por ejemplo, la pasarela de salida o un host externo) y cómo se debe gestionar el tráfico cuando se enruta al destino.

Usa una sola regla de destino para varios hosts de destino para especificar explícitamente cómo se debe proteger el tráfico de los proxies sidecar a la puerta de enlace. Como se ha explicado anteriormente, el método preferido es que las cargas de trabajo envíen solicitudes de texto sin cifrar y que el proxy sidecar origine una conexión mTLS a la puerta de enlace.

Usa una regla de destino para cada host externo con el fin de configurar la pasarela de salida para que actualice las solicitudes HTTP sin cifrar y use una conexión TLS (HTTPS) al reenviar a la dirección de destino. La actualización de una conexión de texto sin formato a TLS se suele denominar creación de TLS.

Controlar el ámbito de la configuración del proxy con el recurso Sidecar

Configura un recurso Sidecar predeterminado para cada espacio de nombres con el fin de controlar el comportamiento de los proxies de sidecar. Usa la propiedad de salida del recurso Sidecar para controlar y minimizar los hosts de destino configurados en los listeners de salida de los proxies. Una configuración mínima típica podría incluir los siguientes destinos para cada espacio de nombres:

  • Pods en el mismo espacio de nombres
  • APIs y servicios de Google
  • Servidor de metadatos de GKE
  • Hosts externos específicos que se han configurado mediante entradas de servicio

La configuración de los listeners de salida en los proxies sidecar no debe considerarse por sí sola como un control de seguridad.

Se recomienda usar recursos de Sidecar para limitar el tamaño de la configuración del proxy. De forma predeterminada, cada proxy adicional de una malla se configura para permitirle enviar tráfico a todos los demás proxies. El consumo de memoria de los proxies sidecar y del plano de control se puede reducir considerablemente restringiendo la configuración de los proxies solo a los hosts con los que necesiten comunicarse.

Usar la política de autorización para permitir o denegar el tráfico en la pasarela de salida

AuthorizationPolicy es un recurso que te permite configurar una política de control de acceso pormenorizado para el tráfico de la malla. Puedes crear políticas para permitir o denegar el tráfico en función de las propiedades de la fuente, el destino o el propio tráfico (por ejemplo, el host o los encabezados de una solicitud HTTP).

Para permitir o denegar conexiones en función de la identidad o el espacio de nombres de la carga de trabajo de origen, la conexión a la pasarela de salida debe autenticarse con mTLS. Las conexiones de los sidecars a la pasarela de salida no usan automáticamente mTLS, por lo que la regla de destino de las conexiones a la pasarela debe especificar explícitamente el ISTIO_MUTUAL modo TLS.

Para permitir o denegar solicitudes en la pasarela mediante políticas de autorización, las cargas de trabajo deben enviar solicitudes HTTP sin cifrar a destinos fuera de la malla. Los proxies sidecar pueden reenviar la solicitud a la pasarela mediante mTLS y la pasarela puede iniciar una conexión TLS segura con el host externo.

Para admitir los requisitos de salida de diferentes equipos y aplicaciones, configura políticas de autorización de "privilegios mínimos" independientes por espacio de nombres o carga de trabajo. Por ejemplo, se pueden aplicar diferentes políticas en la puerta de enlace de salida especificando reglas basadas en el espacio de nombres de la carga de trabajo de origen y en los atributos de la solicitud, como se indica a continuación:

  • Si el espacio de nombres de origen es equipo-x Y el host de destino es example.com, permite el tráfico.

    Ejemplo de políticas de autorización

  • Si el espacio de nombres de origen es equipo-y Y el host de destino es httpbin.org Y la ruta es /status/418, permite el tráfico.

    Políticas de autorización con httpbin

El resto de las solicitudes se deniegan.

Configurar la pasarela de salida para que origine conexiones TLS (HTTPS) al destino

Configura reglas de destino para que la pasarela de salida origine conexiones TLS (HTTPS) a destinos externos.

Para que funcione la creación de TLS en la pasarela de salida, las cargas de trabajo deben enviar solicitudes HTTP sin cifrar. Si la carga de trabajo inicia TLS, la pasarela de salida envolverá TLS sobre el TLS original y las solicitudes al servicio externo fallarán.

Como las cargas de trabajo envían solicitudes HTTP sin cifrar, configura el proxy sidecar de la carga de trabajo para que establezca una conexión mTLS al enviarlas a la pasarela. A continuación, la pasarela de salida finaliza la conexión mTLS y origina una conexión TLS (HTTPS) normal al host de destino.

Creación de TLS en la pasarela de salida

Este enfoque tiene varias ventajas:

  • Puedes usar una política de autorización para permitir o denegar el tráfico en función de los atributos de la carga de trabajo de origen y de las solicitudes.

  • El tráfico entre los pods de carga de trabajo y la pasarela de salida está cifrado y autenticado (mTLS), y el tráfico entre la pasarela de salida y el destino está cifrado (TLS/HTTPS).

  • Dentro de la malla, los proxies sidecar pueden observar y actuar en función de las propiedades de las solicitudes HTTP (por ejemplo, los encabezados), lo que proporciona opciones adicionales de observabilidad y control.

  • El código de la aplicación se puede simplificar. Los desarrolladores no tienen que ocuparse de los certificados ni de las bibliotecas de cliente HTTPS, y la malla de servicios puede asegurar la comunicación con cifrados estándar y actualizados.

  • Las conexiones TLS que la pasarela de salida origina a servicios externos se pueden reutilizar para el tráfico de muchos pods. La reutilización de conexiones es más eficiente y reduce el riesgo de alcanzar los límites de conexión.

DNS, nombres de host y comodines

Cuando enrutes, deniegues o permitas el tráfico en función del host de destino, debes confiar plenamente en la integridad de tus sistemas DNS para resolver los nombres DNS en la dirección IP correcta. En los clústeres de Kubernetes Engine, el servicio DNS de Kubernetes gestiona las consultas de DNS y, a su vez, delega las consultas externas en el servidor de metadatos de GKE y en el DNS interno. Define el atributo de resolución de las entradas de servicio como DNS al enrutar a hosts externos para que los proxies sidecar se encarguen de hacer las consultas de DNS.

Cloud Service Mesh puede enrutar el tráfico en función de hosts comodín. El caso más sencillo es un comodín para los hosts que comparten un nombre común y están alojados en un conjunto común de servidores. Por ejemplo, si un único conjunto de servidores puede servir los dominios que coinciden con *.example.com, se puede usar un host comodín.

Una pasarela de salida estándar no puede reenviar datos en función de hosts comodín más generales y arbitrarios (por ejemplo, *.com) debido a ciertas limitaciones del proxy Envoy que usa Istio. Envoy solo puede enrutar el tráfico a hosts predefinidos, direcciones IP predefinidas o a la dirección IP de destino original de una solicitud. Cuando se usa una pasarela de salida, se pierde la IP de destino original de la solicitud, ya que se sustituye por la IP de la pasarela y los hosts de destino arbitrarios no se pueden preconfigurar.

Aplicación administrativa de las políticas

Usar el control de acceso basado en roles (RBAC) de Kubernetes

Solo los administradores autorizados deberían poder configurar los controles de salida. Configura el control de acceso basado en roles (RBAC) de Kubernetes para evitar que se eludan los controles de salida sin autorización. Aplica roles de control de acceso basado en roles para que solo los administradores de red puedan gestionar los espacios de nombres istio-egress, istio-system, y kube-system, así como los siguientes recursos:

  • Sidecar
  • ServiceEntry
  • Pasarela
  • AuthorizationPolicy
  • NetworkPolicy

Restringir el uso de tolerancias

Como se ha descrito anteriormente, puedes usar taints y tolerations para evitar que los pods de carga de trabajo se implementen en nodos de pasarela. Sin embargo, de forma predeterminada, no hay nada que impida que las cargas de trabajo se desplieguen con una tolerancia para los nodos de la pasarela y, por lo tanto, que se omitan los controles de salida. Si es posible aplicar un control administrativo centralizado sobre las canalizaciones de implementación, puedes usarlas para aplicar restricciones al uso de determinadas claves de tolerancia.

Otra opción es usar el control de admisión de Kubernetes. Anthos incluye un componente llamado Policy Controller, que actúa como controlador de admisión de Kubernetes y valida que las implementaciones cumplan las restricciones de las políticas que especifiques.

Asegurarse de que se registra el tráfico

A menudo es necesario registrar todo el tráfico que cruza los perímetros de la red. El registro del tráfico es esencial si debes demostrar que cumples los reglamentos de protección de datos habituales. Los registros de tráfico se envían directamente a Cloud Logging y se puede acceder a ellos desde los paneles de control de Cloud Service Mesh en la consola de Google Cloud . Puede filtrar los registros en función de varios atributos, como el origen o el destino, la identidad, el espacio de nombres, los atributos del tráfico y la latencia.

Para facilitar la depuración con kubectl, habilita el registro del tráfico en stdout al instalar Cloud Service Mesh mediante el ajuste accessLogFile.

Los registros de auditoría se envían a Cloud Logging cada vez que la AC de Mesh crea un certificado para una carga de trabajo.

Considera la posibilidad de usar un clúster independiente para las pasarelas de salida en mallas de varios clústeres

Cloud Service Mesh se puede desplegar en más de un clúster de GKE. Las mallas multiclúster introducen nuevas posibilidades para controlar el tráfico de salida, así como algunas limitaciones.

En lugar de desplegar la pasarela de salida en un grupo de nodos dedicado, puedes desplegarla en un clúster independiente que no ejecute cargas de trabajo normales. Si usas un clúster independiente, se consigue un aislamiento similar entre las cargas de trabajo y las pasarelas, sin necesidad de usar taints ni tolerancias. La pasarela de salida puede compartir el clúster independiente con las pasarelas de entrada u otros servicios centrales.

Puedes usar políticas de red de Kubernetes en implementaciones multiclúster, pero, como operan en la capa 4 (transporte), no pueden restringir las conexiones entre clústeres en función del espacio de nombres o del pod de destino.

Siguientes pasos