La capa de redes virtuales en Google Distributed Cloud (GDC) aislada del aire rige la conectividad, los firewalls, el descubrimiento de servicios, el balanceo de cargas y la observabilidad entre las máquinas virtuales y los Pods que se ejecutan en una organización de GDC.
Modelo de redes de GDC
GDC contiene dos niveles de conceptos de múltiples arrendatarios: organizaciones y proyectos. Los proyectos existen dentro de las organizaciones, y tú implementas todas las cargas de trabajo virtualizadas y en contenedores en un proyecto específico dentro de una organización.
Conexiones de organizaciones
Cada organización en GDC tiene su propia red virtual aislada. La red virtual dentro de la organización es un espacio IP plano, lo que significa que todas las cargas de trabajo de la organización tienen conectividad directa de direcciones IP entre sí. Con las políticas de red del proyecto, puedes controlar el acceso entre las cargas de trabajo de diferentes proyectos de la organización.
GDC aísla a cada organización a nivel de la red de todas las demás organizaciones. Las cargas de trabajo de una organización no tienen conectividad directa de dirección IP con las cargas de trabajo de otra organización.
Una organización tiene dos rangos de IP diferentes: un rango interno y un rango externo. Se puede acceder al rango de IP externas desde fuera de la organización, y solo se puede acceder al rango de IP internas desde dentro de la organización. A las cargas de trabajo siempre se les asigna una dirección IP del rango interno de la organización, lo que significa que, de forma predeterminada, no se puede acceder a ellas desde fuera de la organización. Debes habilitar de forma explícita el tráfico entrante y saliente para las cargas de trabajo con las restricciones de entrada y salida que se describen en la sección Redes del proyecto.
Conexión de proyectos
Implementas todas las máquinas virtuales (VM) y las cargas de trabajo en contenedores en un proyecto. Los proyectos proporcionan un límite de segmentación de red dentro de la organización.
Las cargas de trabajo dentro de un proyecto pueden comunicarse directamente entre sí. Sin embargo, la política de red predeterminada impide la comunicación entre cargas de trabajo en diferentes proyectos. Las políticas de red del proyecto (ProjectNetworkPolicy) te permiten configurar qué proyectos de la organización pueden comunicarse entre sí. Si la política de red del proyecto lo permite, las cargas de trabajo de la organización pueden comunicarse entre sí en la capa de red L3 con sus respectivas direcciones IP. Debes habilitar de forma explícita las restricciones de entrada y salida hacia y desde la organización para cada carga de trabajo que requiera tráfico entrante o saliente.
Configura los balanceadores de cargas
Los balanceadores de cargas distribuyen el tráfico entre las cargas de trabajo de backend de tu aplicación, lo que garantiza la estabilidad y la disponibilidad. Crea balanceadores de cargas externos e internos para cargas de trabajo de pods y VM. GDC proporciona tres métodos para configurar balanceadores de cargas. Para obtener más información, consulta Administra balanceadores de cargas.
Restricciones de entrada
El mecanismo que se usa para exponer cargas de trabajo fuera de la organización difiere según si la carga de trabajo se basa en VMs o contenedores.
Expones cargas de trabajo basadas en VMs fuera de la organización con la capacidad de acceso externo a la VM. Habilita esta capacidad para cada VM. Cada VM obtiene su propia dirección IP del rango externo de la organización.
Por otro lado, expones cargas de trabajo en contenedores fuera de la organización con la función de balanceador de cargas externo. Puedes crear un balanceador de cargas externo, y GDC asigna una dirección IP externa. Luego, se puede realizar el balanceo de cargas del tráfico en un conjunto de cargas de trabajo de Pod de backend.
Restricciones de salida
Debes habilitar de forma explícita el tráfico saliente para que cada proyecto y carga de trabajo se comuniquen fuera de la organización. Habilitar el tráfico saliente cambia la IP de las cargas de trabajo a una IP externa con la traducción de direcciones de red (NAT) cuando se conecta fuera de la organización. Para obtener más información sobre cómo permitir el tráfico saliente, consulta Administra el tráfico saliente de una organización.
Modelo de aplicación de políticas de red
La postura de seguridad para las cargas de trabajo dentro de una organización es la unión de las políticas de red del proyecto predeterminadas y creadas por el usuario.
La aplicación de políticas se basa en los flujos de tráfico de capa 3 y capa 4. Un flujo describe una conexión de 5 tuplas de la siguiente manera:
- Dirección IP de origen
- Dirección IP de destino
- Puerto de origen
- Puerto de destino
- Protocolo, como
TCPoUDP
Las políticas de red aplican la política de tráfico saliente en el tráfico del nodo que aloja la carga de trabajo de origen y la política de tráfico entrante cuando el tráfico llega al nodo que aloja la carga de trabajo de destino. Por lo tanto, para establecer una conexión, debes permitir que la política salga de la fuente hacia el destino y llegue al destino desde la fuente.
El tráfico de respuesta, como el segmento SYN-ACK (sincronizar-confirmar) que responde a un segmento SYN, no está sujeto a la aplicación de la política. Por lo tanto, el tráfico de respuesta siempre se permite si se permite el tráfico de inicio. Por este motivo, solo observas tiempos de espera de conexión debido a la aplicación de políticas desde el cliente que inicia la conexión. El tráfico rechazado se descarta durante la transferencia de datos saliente desde el nodo de origen o la transferencia de datos entrante en el nodo de destino. La carga de trabajo receptora nunca observa la conexión.
La aplicación se basa en reglas de políticas que permiten el acceso y son aditivas. La aplicación resultante para una carga de trabajo es una "coincidencia cualquiera" para el flujo de tráfico en comparación con la unión de todas las políticas aplicadas a esa carga de trabajo. Cuando hay varias políticas, las reglas que se aplican a cada carga de trabajo se combinan de forma aditiva, lo que permite el tráfico si coincide con al menos una de las reglas. No tienes reglas de denegación, solo de permiso.
Cuando una política de red rechaza un flujo, no recibes un paquete de respuesta y observas un tiempo de espera de conexión. Por este motivo, las conexiones a nivel del protocolo rechazadas o restablecidas, o los errores de HTTP no son el resultado directo de la aplicación de la red.
Para obtener más información sobre las políticas de red de Kubernetes, consulta https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation.