Prácticas recomendadas para usar las puertas de enlace de salida de Cloud Service Mesh en los clústeres de GKE
En este documento, se describe cómo usar las puertas de enlace de salida de Cloud Service Mesh y otros controles de Google Cloud para proteger el tráfico saliente (salida) de las cargas de trabajo implementadas en un clúster de Google Kubernetes Engine (GKE). Estos controles pueden limitar las conexiones a los servicios externos según 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.
El público previsto para este documento incluye ingenieros de redes, seguridad y plataforma que administran los clústeres de GKE que usan uno o más equipos de entrega de software. Los controles que se describen aquí pueden ser especialmente útil para las organizaciones que deben demostrar el cumplimiento de reglamentarias (por ejemplo, RGPD y PCI).
Introducción
El enfoque tradicional de seguridad en la red ha sido definir los perímetros de seguridad en torno a un grupo de aplicaciones. En estos perímetros, se usan firewalls para permitir o denegar el tráfico según las direcciones IP de origen y destino, mientras se confían en las aplicaciones y el tráfico incluidos en el perímetro. Sin embargo, esta confianza implica riesgos. Un usuario malintencionado con información privilegiada o cualquier persona que comprometa el perímetro puede moverse libremente dentro de la red, acceder a los datos y exponerlos, atacar sistemas de terceros e interferir en sistemas de administración.
Cuando las cargas de trabajo que se ejecutan en un clúster de Kubernetes realizan conexiones de salida a hosts en Internet, puede ser complicado aplicar controles de seguridad tradicionales basados en IP debido a lo siguiente:
Las direcciones IP del Pod no representan de forma adecuada la identidad de la carga de trabajo que realiza la conexión. En un entorno de Kubernetes, las direcciones IP del Pod se asignan de forma efímera y se reciclan con frecuencia cuando entran y salen los Pods.
A menudo, es imposible identificar un conjunto pequeño y fijo de direcciones IP para hosts de destino particulares. Las direcciones IP cambian con frecuencia, varían según la región y pueden provenir de grandes rangos o representar cachés, proxies o CDN.
Varios equipos que comparten el mismo clúster de múltiples usuarios, con un rango compartido de IP de origen, pueden tener diferentes requisitos de conectividad externa.
Cloud Service Mesh es una malla de servicios completamente administrada en Google Cloud basada en la malla de servicios de Istio de código abierto. Una malla de servicios proporciona una manera uniforme de conectar, administrar y proteger la comunicación de la aplicación. Las mallas de servicios adoptan un enfoque centrado en la aplicación y usan identidades de aplicaciones confiables en lugar de un enfoque enfocado en la IP de red.
Puedes implementar una malla de servicios de forma transparente sin necesidad de modificar el código de la aplicación existente. Usar una malla de servicios ayuda a separar el trabajo de los equipos de desarrollo que son responsables de entregar y lanzar funciones de la aplicación de las responsabilidades de los administradores de red, ya que proporciona un control declarativo del comportamiento de la red.
Cloud Service Mesh proporciona la opción de implementar proxies de reenvío independientes,conocidos como puertas de enlace de salida, en el perímetro de la malla. En esta guía, se explica cómo las funciones del proxy de puerta de enlace de salida se pueden combinar con las características de Google Cloud para controlar, autorizar y observar el tráfico saliente de las cargas de trabajo implementadas en un clúster de GKE.
Arquitectura de defensa en profundidad
En el siguiente diagrama, se muestra una arquitectura que toma un enfoque de defensa en profundidad al control detallado del tráfico de salida para un clúster que usan varios equipos. Los controles se basan en Capa 4 (transporte) y Capa 7 (aplicación) controles de red.
La arquitectura usa los siguientes recursos y controles:
Un clúster de GKE privado: los nodos en un clúster de GKE privado solo tienen direcciones IP internas y no se conectan a Internet de forma predeterminada.
Cloud NAT: Cloud NAT permite el acceso saliente a Internet desde el clúster privado.
Reglas de firewall de la nube privada virtual (VPC): Configura reglas de firewall de VPC para aplicar controles de capa 4 (Transporte) a conexiones desde y hacia los nodos en el clúster de GKE. Puedes aplicar reglas de firewall de VPC a las VM basadas en cuentas de servicio o etiquetas de red.
Grupos de nodos de GKE con cuentas de servicio diferentes: Te permite configurar diferentes reglas de firewall para que se apliquen según el grupo de nodos al que pertenece un nodo.
Espacios de nombres de Kubernetes: Crea espacios de nombres para cada equipo a fin de proporcionar aislamiento y control administrativo delegado. Los administradores de red usan un espacio de nombres dedicado para implementar la puerta de enlace 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 tiene un alcance a un espacio de nombres y puede tener un alcance más preciso a Pods específicos en un espacio de nombres.
Una puerta de enlace de salida: El tráfico que sale de los Pods dentro de la malla se dirige mediante proxies de puerta de enlace de salida exclusivos que se ejecutan en nodos dedicados. Implementa puertas de enlace de salida con un escalador automático de Pod horizontal para que la cantidad de réplicas aumente y disminuya con el tráfico.
Políticas de autorización: Usa políticas de autorización de malla para aplicar controles de capa 7 (aplicación) al tráfico entre los Pods dentro de la malla y el tráfico que sale de la malla.
Recursos de sidecar: Se usan recursos de archivo adicional para controlar el alcance de la configuración de los proxies de sidecar que se ejecutan en cada Pod de carga de trabajo. Puedes usar el recurso de sidecar para configurar los espacios de nombres, Pods y 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 API de Google y extraigan imágenes de Docker desde Container Registry.
Workload Identity de GKE : Con Workload Identity, puedes usar Identity and Access Management (IAM) para otorgar permisos a la API a cargas de trabajo específicas mediante el principio de privilegio mínimo sin la necesidad de procesar Secrets.
Configura controles de salida
Si usas la puerta de enlace de salida para proteger el tráfico de salida desde tu malla, te recomendamos que configures los controles de defensa en profundidad que se describen en esta sección.
Usa 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 satisface este requisito. Puedes configurar el modo nativo de la VPC en tu clúster privado para que los Pods y servicios tengan direcciones IP de rangos secundarios en la VPC. Las direcciones IP del Pod nativo de la VPC se pueden enrutar de forma nativa dentro de la red de VPC.
Algunas cargas de trabajo pueden requerir acceso 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 tener direcciones IP públicas, configura Cloud NAT para proporcionar la traducción de direcciones de red (NAT).
Asegúrate de que Cloud NAT esté configurado para que la puerta de enlace de salida pueda realizar una cantidad suficiente de conexiones simultáneas a destinos externos. Para evitar el agotamiento del puerto y problemas con las demoras en la reutilización de conexiones, configura la cantidad mínima de puertos por VM de forma adecuada. Consulta la descripción general de la dirección y el puerto de Cloud NAT para obtener más detalles. Aumentar la cantidad de réplicas de puerta de enlace de salida puede ayudar a reducir las posibilidades de conflictos de asignación independientes del extremo.
Configura el acceso privado a Google de los servicios y las API de Google
Es probable que tus cargas de trabajo necesiten acceso a las API y los servicios de Google. Usa el acceso privado a Google con zonas DNS personalizadas para permitir la conectividad de las subredes de VPC privadas a las API de Google mediante un conjunto de cuatro direcciones IP. Cuando se usan estas direcciones IP, no es necesario que los Pods tengan 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), dependiendo de si usas los Controles del servicio de VPC.
Usa IAM y Workload Identity para proteger aún más las API y los servicios de Google
El uso de Workload Identity es la forma recomendada de permitir que las cargas de trabajo de GKE se autentiquen con las API de Google y que los administradores apliquen controles de autorización de “mínimo privilegio” con IAM.
Cuando usas el Acceso privado a Google, IAM y Workload Identity, puedes permitir de forma segura los Pods de cargas de trabajo para omitir la puerta de enlace de salida y conectarte directamente a las API y los servicios de Google.
Usa espacios de nombres de Kubernetes para el control administrativo
Los espacios de nombres son un recurso organizativo que es útil en entornos en los que hay muchos usuarios o equipos. Pueden considerarse como un clúster virtual, y permiten que la responsabilidad administrativa de los grupos de recursos de Kubernetes se delegue a distintos administradores.
Los espacios de nombres son una función importante para el aislamiento del 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 utilizándolos como un unidad de usuario dentro de una malla de servicios. Las políticas de autorización de malla y los recursos de sidecar pueden restringir la visibilidad y el acceso según los atributos de espacio de nombres, identidad y 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 las conexiones de red en la capa 4 (transporte).
Ejecuta puertas de enlace de salida en nodos de puerta de enlace dedicados
Ejecutar puertas de enlace de salida en nodos en un grupo de nodos de puerta de enlace dedicado ofrece varias ventajas. Los nodos externos pueden usar una configuración endurecida y puedes configurar las reglas del firewall de VPC para evitar que las cargas de trabajo lleguen a hosts externos directamente. Los grupos de nodos se pueden tener un ajuste de escala automático independiente mediante el escalador automático del clúster.
Para permitir un control administrativo separado en la puerta de enlace de salida, impleméntalo en un espacio de nombres istio-egress dedicado. 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 el control de implementación, usa un selector de nodos en la implementación de la puerta de enlace de salida para que se ejecute en nodos que estén etiquetados como miembros del grupo de nodos de puerta de enlace.
Asegúrate de que solo los Pods de puerta de enlace se puedan ejecutar en nodos de puerta de enlace. Los demás Pods deben quitarse de los nodos de puerta de enlace; de lo contrario, los controles de salida se podrían omitir. Se puede evitar que las cargas de trabajo se ejecuten en ciertos nodos mediante el uso de taints y tolerancias. Debes aplicar un taint a los nodos en el grupo de nodos de puerta de enlace y agregar una tolerancia correspondiente a la implementación de la puerta de enlace de salida.
Aplica reglas de firewall de VPC a nodos específicos
Configura el enrutamiento de la malla de servicios para dirigir el tráfico de salida desde las cargas de trabajo que se ejecutan en el grupo de nodos predeterminado mediante las puertas de enlace de salida que se ejecutan en el grupo de nodos de puerta de enlace. Sin embargo, no se debe confiar en la configuración de enrutamiento de la malla como un límite de seguridad, porque existen varias formas en las que una carga de trabajo puede omitir los proxies de malla.
Para evitar que las cargas de trabajo de la aplicación se conecten directamente a los hosts externos, aplica reglas de firewall de salida restringidas a los nodos en el grupo de nodos predeterminado. Aplica reglas de firewall independientes a los nodos de puerta de enlace para que los Pods de puerta de enlace de salida que se ejecutan en ellos puedan conectarse a hosts externos.
Cuando crees una regla de firewall de VPC, especifica los puertos y protocolos que la regla de firewall permite o rechaza y 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 se aplican al tráfico entrante. La configuración predeterminada para la salida es allow y para la entrada es deny.
Las reglas de firewall se aplican en orden según un número de prioridad que puedes especificar. Las reglas de firewall tienen estado, lo que significa que, si se permite el tráfico específico de una VM, también se permite mostrar el tráfico con la misma conexión.
En el siguiente diagrama, se muestra cómo se pueden aplicar reglas de firewall independientes a los nodos en dos grupos de nodos diferentes según la cuenta de servicio asignada a un nodo. En este caso, una regla de firewall deny all predeterminada rechaza el acceso de salida para toda la VPC. A fin de evitar anular reglas de firewall predeterminadas esenciales para que funcione tu clúster, tu regla deny all debe usar una prioridad baja, como 65535. Se aplica una regla de firewall de salida aditiva y de mayor prioridad a los nodos de puerta de enlace para permitirles conectarse directamente a hosts externos en los puertos 80 y 443. El grupo de nodos predeterminado no tiene acceso a hosts externos.
Usa las políticas de red de Kubernetes como un firewall para los Pods y los espacios de nombres
Usa Políticas de red de Kubernetes aplicar una capa extra de seguridad como parte de una estrategia de defensa en profundidad. 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 los Pods dentro de un espacio de nombres
- A puertos y bloques de IP en particular
Una vez que una política de red selecciona Pods en un espacio de nombres, se rechazan las conexiones que no se permitan de forma explícita. Cuando se aplican varias políticas de red, el resultado es aditivo y es una unión de las políticas. No importa el orden en el que se aplican las políticas.
Algunos ejemplos de políticas de red incluyen los siguientes:
- Permite conexiones de salida desde los espacios de nombres de la carga de trabajo hacia los espacios de nombres
istio-systemyistio-egress. Los Pods deben poder conectarse al plano de control y a la puerta de enlace de salida. - Permite que las cargas de trabajo realicen consultas de DNS desde los espacios de nombres de la carga de trabajo hacia el puerto 53 en el espacio de nombres
kube-system. - De manera opcional, permite que las cargas de trabajo en el mismo espacio de nombres se conecten entre sí.
- De manera opcional, permite conexiones de salida entre los espacios de nombres que usan los diferentes equipos de aplicaciones.
- Permite conexiones de salida desde espacios de nombres de cargas de trabajo hacia las VIP para las API de Google (expuestas mediante el uso del Acceso privado a Google) Cloud Service Mesh proporciona una AC administrada y la expone como una API, por lo que los proxies de sidecar deben poder conectarse a ella. También es posible que algunas cargas de trabajo necesiten acceso a las API de Google.
- Permite conexiones de salida desde espacios de nombres de cargas de trabajo hacia el servidor de metadatos de GKE para que los proxies de sidecar y las cargas de trabajo puedan realizar consultas de metadatos y autenticarse en las API de Google
De forma predeterminada, cuando se inserta un proxy de sidecar en un Pod de carga de trabajo, se programan reglas iptables para que el proxy capture todo el tráfico de TCP entrante y saliente. Sin embargo, como se mencionó anteriormente, hay maneras para que las cargas de trabajo omitan el proxy. Las reglas de firewall de VPC evitan el acceso directo de salida desde los nodos predeterminados que ejecutan las cargas de trabajo. Puedes usar las políticas de red de Kubernetes para asegurarte de que no haya una salida externa directa desde los espacios de nombres de cargas de trabajo y que sea posible salir al espacio de nombres istio-egress.
Si también controlas la entrada con políticas de red, debes crear políticas de entrada para que se coincidan con tus políticas de salida.
Configuración y seguridad de Service Mesh
Las cargas de trabajo que se ejecutan en una malla de servicios no se identifican según sus direcciones IP. Cloud Service Mesh asigna una identidad sólida y comprobable en la de un certificado X.509 y de cada carga de trabajo. La comunicación de confianza entre cargas de trabajo se establece con conexiones TLS mutuas (mTLS) autenticadas y encriptadas.
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 malla para un control detallado sobre cómo las cargas de trabajo pueden comunicarse con servicios externos.
Aunque el tráfico puede abandonar la malla directamente desde los proxies de sidecar, si necesitas control adicional, te recomendamos enrutar el tráfico a través de las puertas de enlace de salida, como se describe en esta guía.
Administra la configuración de los controles de salida en un espacio de nombres dedicado
Permite que los administradores de red administren de forma centralizada los controles usando un espacio de nombres istio-egress dedicado para la configuración de malla relacionada con la salida. Como se recomendó con anterioridad, debes implementar la puerta de enlace de salida en el espacio de nombres istio-egress. En este espacio de nombres puedes crear y administrar entradas de servicio, puertas de enlace y políticas de autorización.
Requiere una configuración explícita de destinos externos
Asegúrate de que los proxies de malla solo se programen con rutas a hosts externos que se definan de manera explícita en el registro de la malla de servicios. Establece el
modo de política de tráfico saliente
a REGISTRY_ONLY en una configuración predeterminada
recurso de sidecar
para cada espacio de nombres. Establecer la política de tráfico saliente para la malla no debe considerarse como un control perimetral seguro por sí mismo.
Define destinos externos con entradas de servicio
Configura Entradas de servicio para registrar de forma explícita hosts externos en el registro de servicio de la malla. De forma predeterminada, las entradas del servicio son visibles para todos los espacios de nombres. Usa el atributo exportTo para controlar los espacios de nombres que puede ver una entrada de servicio. Las entradas de servicio determinan las rutas salientes que están configuradas en proxies de malla, pero no se consideran por sí solas un control seguro para determinar a qué cargas de host externas se pueden conectar.
Configura el comportamiento de la puerta de enlace de salida con el recurso Gateway
Configura el comportamiento del balanceo de cargas de las puertas de enlace de salida mediante Puerta de enlace recurso. El balanceador de cargas se puede configurar para un conjunto particular de hosts, protocolos y puertos, y asociar con una implementación de puerta de enlace de salida. Por ejemplo, se puede configurar una puerta de enlace para la salida a los puertos 80 y 443 para cualquier host externo.
En Cloud Service Mesh, la mTLS automática está habilitada de forma predeterminada. Con la mTLS automática, un proxy de 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 puerta de enlace de salida desde los proxies de sidecar no usa de forma automática mTLS. Para indicar cómo se deben proteger las conexiones a la puerta de enlace de salida, debes configurar el modo TLS en el recurso Gateway. Siempre que sea posible, usa mTLS para conexiones de proxies de sidecar a la puerta de enlace de salida.
Es posible permitir que las cargas de trabajo inicien por sí mismas conexiones TLS (HTTPS). Si las cargas de trabajo originan conexiones TLS, generalmente en el puerto 443, debes configurar la puerta de enlace para que use el modo passthrough en las conexiones de ese puerto. Sin embargo, usar el modo passthrough significa que la puerta de enlace no puede aplicar políticas de autorización según la identidad de la carga de trabajo o las propiedades de la solicitud encriptada. Además, actualmente no es posible usar mTLS y passthrough juntos.
Configura servicios virtuales y reglas de destino para enrutar el tráfico a través de la puerta de enlace
Usa servicios virtuales y reglas de destino para configurar el enrutamiento de tráfico desde los proxies de sidecar a través de la puerta de enlace de salida hacia 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 puerta de enlace de salida o un host externo) y cómo se debe manejar el tráfico cuando se enruta al destino.
Usa una sola regla de destino para varios hosts de destino a fin de especificar de forma explícita cómo se debe proteger el tráfico desde los proxies de sidecar hacia la puerta de enlace. Como se explicó antes, el método preferido es que las cargas de trabajo envíen solicitudes de texto sin formato y que el proxy de sidecar origine una conexión mTLS a la puerta de enlace.
Usa una regla de destino para cada host externo a fin de configurar la puerta de enlace de salida para que "actualice" solicitudes HTTP simples a fin de usar una conexión TLS (HTTPS) cuando se redireccione al destino. La actualización de una conexión de texto sin formato a TLS se suele denominar TLS de origen.
Controla el alcance de la configuración del proxy con el recurso de sidecar
Configurar una configuración predeterminada Recurso de sidecar en cada espacio de nombres para controlar el comportamiento de los proxies de sidecar. Usa el propiedad de salida del recurso de archivo adicional para controlar y minimizar los hosts de destino configurados en los objetos de escucha 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
- API y servicios de Google
- El servidor de metadatos de GKE
- Hosts externos específicos que se configuraron mediante entradas de servicio
La configuración de los objetos de escucha salientes en los proxies de sidecar no debe considerarse como controles de seguridad por sí solos.
La práctica recomendada es usar los recursos de sidecar para limitar el tamaño de la configuración del proxy. De forma predeterminada, cada proxy de sidecar en una malla está configurado para permitir que envíe tráfico a todos los demás proxies. El consumo de memoria de los proxies de sidecar y del plano de control se puede reducir en gran medida mediante la restricción de la configuración de los proxies a solo los hosts con los que se deben comunicar.
Usa la política de autorización para permitir o denegar el tráfico en la puerta de enlace de salida
AuthorizationPolicy es un recurso que te permite configurar políticas de control de acceso para el tráfico en malla. Puedes crear políticas para permitir o denegar el tráfico según las propiedades de la fuente, el destino o el tráfico en sí (por ejemplo, el host o los encabezados de una solicitud HTTP).
Para permitir o rechazar conexiones según la identidad o el espacio de nombres de la carga de trabajo de origen, la conexión a la puerta de enlace de salida debe autenticarse con mTLS. Las conexiones de sidecars a la puerta de enlace de salida no usan de forma automática mTLS, por lo que la regla de destino para las conexiones a la puerta de enlace debe especificar explícitamente el modo TLS ISTIO_MUTUAL.
Para permitir o rechazar solicitudes en la puerta de enlace mediante políticas de autorización, las cargas de trabajo deben enviar solicitudes HTTP simples a destinos fuera de la malla. Luego, los proxies de sidecar pueden reenviar la solicitud a la puerta de enlace mediante mTLS y esta puede originar una conexión TLS segura al host externo.
Para admitir los requisitos de salida de diferentes equipos y aplicaciones, configura distintas políticas de autorización de “privilegio mínimo” por espacio de nombres o carga de trabajo. Por ejemplo, se pueden aplicar políticas diferentes en la puerta de enlace de salida mediante la especificación de reglas basadas en el espacio de nombres de la carga de trabajo de origen y los atributos de la solicitud de la siguiente manera:
Si el espacio de nombres de origen es team-x Y el host de destino es example.com, entonces permite el tráfico.
Si el espacio de nombres de origen es team-y Y el host de destino es httpbin.org Y la ruta de acceso es /status/418, entonces permite el tráfico.
Se denegerán todas las demás solicitudes.
Configura la puerta de enlace de salida para originar conexiones TLS (HTTPS) en el destino
Configura las reglas de destino para que la puerta de enlace de salida genere conexiones TLS (HTTPS) a destinos externos.
Para que la TLS de origen a la puerta de enlace de salida funcione, las cargas de trabajo deben enviar solicitudes HTTP simples. Si la carga de trabajo inicia TLS, la puerta de enlace de salida une TLS superpuesta a la TLS original, y fallan las solicitudes al servicio externo.
Debido a que las cargas de trabajo envían solicitudes HTTP simples, configura el proxy de sidecar de la carga de trabajo para establecer una conexión mTLS cuando las envíe a la puerta de enlace. Luego, la puerta de enlace de salida finaliza la conexión mTLS y genera una conexión TLS (HTTPS) normal al host de destino.
Este enfoque tiene varias ventajas:
Puedes usar una política de autorización para permitir o denegar el tráfico según los atributos de la carga de trabajo de origen y las solicitudes.
El tráfico entre los Pods de carga de trabajo y la puerta de enlace de salida se encripta y se autentica (mTLS) y el tráfico entre la puerta de enlace de salida y el destino se encripta (TLS/HTTPS).
Dentro de la malla, los proxies de sidecar pueden observar y actuar sobre las propiedades de las solicitudes HTTP (por ejemplo, encabezados) y proporcionar opciones adicionales para la observabilidad y el control.
El código de la aplicación se puede simplificar. No es necesario que los desarrolladores lidien con certificados o bibliotecas cliente HTTPS, y la malla de servicios puede garantizar una comunicación segura con los algoritmos de cifrado estándar y actualizados.
Las conexiones TLS que origina la puerta de enlace de salida a servicios externos pueden reutilizarse para el tráfico desde 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 enrutas, deniegas o permites el tráfico según el host de destino, debes tener plena confianza en la integridad de tus sistemas de DNS para resolver los nombres de DNS a la dirección IP correcta. En los clústeres de Kubernetes Engine, el servicio de DNS de Kubernetes controla las consultas de DNS y, a su vez, delega las consultas externas al servidor de metadatos de GKE y el DNS interno. Configura el atributo de resolución de las entradas de servicio a DNS cuando se enruta a hosts externos, de manera que los proxies de sidecar sean responsables de realizar consultas de DNS.
Cloud Service Mesh puede enrutar el tráfico según los hosts comodín. El caso más simple es un comodín para los hosts que comparten un nombre común y que se alojan en un conjunto común de servidores. Por ejemplo, si un solo conjunto de servidores puede entregar los dominios que coinciden con *.example.com, se puede usar un host comodín.
Una puerta de enlace de salida estándar no se puede reenviar según hosts comodín más generales y arbitrarios (por ejemplo, *.com) debido a ciertas limitaciones del proxy de 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 puerta de enlace de salida, la IP de destino original de la solicitud se pierde porque se reemplaza con la IP de la puerta de enlace y los hosts de destino arbitrarios no se pueden preconfigurar.
Aplicación administrativa de políticas
Usa el control de acceso basado en funciones (RBAC) de Kubernetes
Solo los administradores autorizados deben poder configurar controles de salida.
Configura el Control de acceso basado en funciones (RBAC) de Kubernetes para evitar la evasión no autorizada de los controles de salida. Aplica funciones de RBAC para que solo los administradores de red puedan administrar los espacios de nombres istio-egress, istio-system, y kube-system, y los siguientes recursos:
- Sidecar
- ServiceEntry
- Puerta de enlace
- AuthorizationPolicy
- NetworkPolicy
Restringe el uso de tolerancias
Como se describió anteriormente, puedes usar taints y tolerancias para evitar que los Pods de cargas de trabajo se implementen en los nodos de puerta de enlace. Sin embargo, de forma predeterminada, no hay nada que impida que se implementen las cargas de trabajo con una tolerancia para los nodos de puerta de enlace y, por lo tanto, permitir 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 sobre el uso de ciertas claves de tolerancia.
Otro enfoque es usar el control de admisión de Kubernetes. Anthos incluye un componente llamado controlador de políticas que actúa como controlador de admisión de Kubernetes y valida que las implementaciones cumplan con las restricciones de la política que especifiques.
Asegúrate de que se registre el tráfico
A menudo, es necesario registrar todo el tráfico que cruza los perímetros de la red. El registro de tráfico es esencial si necesitas demostrar que se cumplen con las regulaciones comunes de protección de datos. Los registros de tráfico se envían directamente a Cloud Logging y se puede acceder a ellos desde los paneles de Cloud Service Mesh en la consola de Google Cloud. Puedes filtrar registros según varios atributos, como el origen o el destino, la identidad, el espacio de nombres, los atributos del tráfico y la latencia.
Para permitir una depuración fácil con kubectl, habilita el registro de tráfico a stdout cuando instales Cloud Service Mesh con la configuración accessLogFile.
Los registros de auditoría se envían a Cloud Logging cada vez que la CA de Mesh crea un certificado para una carga de trabajo.
Considera usar un clúster separado para puertas de enlace de salida en mallas de varios clústeres
La malla de servicios de Cloud implementados en más de un clúster de GKE. Las mallas de varios clústeres presentan nuevas posibilidades para controlar el tráfico de salida y, también, algunas limitaciones.
En lugar de implementar la puerta de enlace de salida en un grupo de nodos dedicado, puedes implementarla en un clúster separado que no ejecute cargas de trabajo habituales. El uso de un clúster separado proporciona un aislamiento similar entre las cargas de trabajo y las puertas de enlace, a la vez que evita la necesidad de taints y tolerancias. La puerta de enlace de salida puede compartir el clúster separado con puertas de enlace de entrada o algún otro servicio central.
Puedes usar las políticas de red de Kubernetes en implementaciones de varios clústeres, sin embargo, debido a que operan en la capa 4 (transporte), no pueden restringir las conexiones entre clústeres según el espacio de nombres o Pod de destino.
¿Qué sigue?
- Consulta la guía de endurecimiento de GKE
- Obtén información para administrar la configuración y la política en toda tu infraestructura con Anthos Configuration Management
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.