La capa de redes virtuales en Google Distributed Cloud (GDC) air-gapped 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 usuarios: organizaciones y proyectos. Los proyectos existen dentro de las organizaciones, y debes implementar todas las cargas de trabajo virtualizadas y en contenedores en un proyecto específico dentro de una organización.
Redes de la organización
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 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 direcciones IP a 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 no se puede acceder a ellas desde fuera de la organización de forma predeterminada. 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.
Redes del proyecto
Implementa 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 las cargas de trabajo de 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 las 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 las cargas de trabajo fuera de la organización difiere según si la carga de trabajo se basa en VMs o contenedores.
Expones las 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 las 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, el tráfico se puede balancear entre un conjunto de cargas de trabajo de pods 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 Descripción general de NAT.
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 la capa 3 y la 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
TCP,UDPoIPIP
Las políticas de red realizan la aplicación del tráfico saliente en el tráfico en el nodo que aloja la carga de trabajo de origen y la aplicación del 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 del origen hacia el destino y llegue al destino desde el origen.
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. Por lo tanto, el tráfico de respuesta siempre se permite si se permite el tráfico de inicio. Por este motivo, solo observas los tiempos de espera de conexión debido a la aplicación de políticas 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 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 basadas en permisos que 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 aplicadas 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 reglas de permiso.
Cuando una política de red deniega un flujo, no recibes un paquete de respuesta y observas un tiempo de espera de conexión. Por este motivo, las conexiones a nivel de protocolo o los errores de HTTP rechazados o restablecidos no son el resultado directo de la aplicación de redes.
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.