La capa de red virtual de Google Distributed Cloud (GDC) con air gap rige la conectividad, los cortafuegos, la detección de servicios, el balanceo de carga y la observabilidad entre las máquinas virtuales y los pods que se ejecutan en una organización de GDC.
Modelo de red de GDC
GDC contiene dos niveles de conceptos de multitenancy: organizaciones y proyectos. Los proyectos se encuentran dentro de las organizaciones y todas las cargas de trabajo virtualizadas y en contenedores se implementan en un proyecto concreto de una organización.
Redes de organizaciones
Cada organización de GDC tiene su propia red virtual aislada. La red virtual de la organización es un espacio de 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 de proyectos, puedes controlar el acceso entre cargas de trabajo de diferentes proyectos de la organización.
GDC aísla cada organización a nivel de red de todas las demás organizaciones. Las cargas de trabajo de una organización no tienen conectividad directa de direcciones IP con las cargas de trabajo de otra organización.
Una organización tiene dos intervalos de IP diferentes: un intervalo interno y un intervalo externo. Se puede acceder al intervalo de IPs externas desde fuera de la organización, mientras que solo se puede acceder al intervalo de IPs internas desde dentro de la organización. A las cargas de trabajo siempre se les asigna una dirección IP del intervalo interno de la organización, lo que significa que, de forma predeterminada, no se puede acceder a ellas desde fuera de la organización. Debe habilitar explícitamente el tráfico entrante y saliente de las cargas de trabajo mediante las restricciones de entrada y salida que se describen en la sección Redes de proyectos.
Redes de proyectos
Todas las máquinas virtuales y las cargas de trabajo contenerizadas se despliegan en un proyecto. Los proyectos proporcionan un límite de segmentación de red dentro de la organización.
Las cargas de trabajo de un proyecto pueden comunicarse directamente entre sí. Sin embargo, la política de red predeterminada impide la comunicación entre las cargas de trabajo de diferentes proyectos. Las políticas de red de proyectos (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 mediante sus respectivas direcciones IP. Debes habilitar explícitamente las restricciones de entrada y salida hacia y desde la organización para cada carga de trabajo que requiera tráfico entrante o saliente.
Configurar balanceadores de carga
Los balanceadores de carga 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 carga externos e internos para cargas de trabajo de pods y VMs. GDC ofrece tres métodos para configurar balanceadores de carga. Para obtener más información, consulta el artículo Gestionar balanceadores de carga.
Restricciones de entrada
El mecanismo que se usa para exponer cargas de trabajo fuera de la organización varía en función de si la carga de trabajo se basa en máquinas virtuales o en contenedores.
Puedes exponer cargas de trabajo basadas en máquinas virtuales fuera de la organización mediante la función de acceso externo a máquinas virtuales. Habilita esta función en cada VM. Cada máquina virtual obtiene su propia dirección IP del intervalo externo de la organización.
Por otro lado, puedes exponer cargas de trabajo en contenedores fuera de la organización mediante la función de balanceador de carga externo. Puedes crear un balanceador de carga externo y GDC le asignará una dirección IP externa. Después, el tráfico se puede balancear entre un conjunto de cargas de trabajo de pods de backend.
Restricciones de salida
Debes habilitar explícitamente el tráfico saliente de cada proyecto y carga de trabajo para que puedan comunicarse fuera de la organización. Si se habilita el tráfico saliente, la IP de las cargas de trabajo cambia a una IP externa mediante la traducción de direcciones de red (NAT) al conectarse fuera de la organización. Para obtener más información sobre cómo permitir el tráfico saliente, consulta el artículo Gestionar el tráfico saliente de una organización.
Modelo de implementación obligatoria de la política de red
La postura de seguridad de las cargas de trabajo de una organización es la unión de las políticas de red de proyectos predeterminadas y creadas por el usuario.
La aplicación de las políticas se basa en los flujos de tráfico de las capas 3 y 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 el tráfico saliente en el nodo que aloja la carga de trabajo de origen y el tráfico entrante en el nodo que aloja la carga de trabajo de destino. Por lo tanto, para establecer una conexión, debe permitir que la política salga del origen hacia el destino y llegue al destino desde el origen.
El tráfico de respuestas, como el segmento SYN-ACK (sincronizar-confirmar) que responde a un segmento SYN, no está sujeto a la aplicación de medidas. Por lo tanto, el tráfico de respuesta siempre se permite si se permite el tráfico inicial. Por este motivo, solo se observan tiempos de espera de conexión debido a la aplicación de políticas por parte del cliente que inicia la conexión. El tráfico denegado se descarta durante la transferencia de datos saliente desde el nodo de origen o durante la transferencia de datos entrante en el nodo de destino. La carga de trabajo receptora nunca observa la conexión.
La implementación se basa en reglas de políticas acumulativas que permiten el acceso. La aplicación resultante de una carga de trabajo es "cualquier coincidencia" para el flujo de tráfico con la unión de todas las políticas aplicadas a esa carga de trabajo. Cuando hay varias políticas, las reglas aplicadas a cada carga de trabajo se combinan de forma acumulativa, 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 deniega un flujo, no recibes un paquete de respuesta y se produce un tiempo de espera de conexión. Por este motivo, las conexiones a nivel de protocolo rechazadas o restablecidas, así como los errores 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.