Directivas de firewall para proteger el tráfico entre los clústeres de Antrea Kubernetes y las máquinas virtuales en una red de NSX

A partir de NSX 4.1, puede crear grupos genéricos con tipos de miembros de Kubernetes en criterios dinámicos de pertenencia para que coincidan con el tráfico entrante y saliente de los clústeres de Antrea Kubernetes.

A continuación, podrá utilizar estos grupos genéricos en reglas de firewall distribuido o reglas de firewall de puerta de enlace para proteger el tráfico entre las máquinas virtuales en el entorno de NSX y los pods de clústeres de Antrea Kubernetes.

Importante: En un entorno de NSX de varios tenants, los recursos del clúster de Kubernetes no se exponen al inventario del proyecto. Por lo tanto, dentro de un proyecto, no se pueden crear grupos genéricos con tipos de miembros de Kubernetes en criterios dinámicos de pertenencia. Debe crear los grupos en la vista Predeterminado (espacio predeterminado) de NSX y, a continuación, consumirlos en las reglas de firewall distribuido o las reglas de firewall de puerta de enlace en el espacio predeterminado.

Proteger el tráfico de los clústeres de Antrea Kubernetes a las máquinas virtuales en NSX

Para buscar la correspondencia entre el tráfico de los clústeres de Antrea Kubernetes con NSX, puede agregar grupos genéricos basados en los siguientes tipos de miembros de Kubernetes (recursos) en las reglas de firewall:

• Nodo de Kubernetes
• Salida de Antrea
• Grupo de direcciones IP de Antrea

El siguiente diagrama muestra los flujos de tráfico típicos del clúster de Antrea Kubernetes a las máquinas virtuales de la red lógica de NSX.

Como se muestra en este diagrama de flujo del tráfico, para buscar correspondencias del tráfico que sale del clúster de AntreaKubernetes, se pueden realizar los siguientes escenarios:

Escenario 1: SNAT a salida (nodos de puerta de enlace)

Puede implementar un recurso de salida en el clúster de Kubernetes de Antrea. En el archivo de manifiesto del recurso de salida, seleccione los criterios de agrupación de los pods a los que se aplica el recurso de salida. Puede especificar la IP de salida manualmente en el archivo de manifiesto, o la CNI de Antrea puede asignar una IP de salida desde un recurso personalizado de ExternalIPPool.

Importante: Las direcciones IP de salida deben ser enrutables en la red física y deben ser accesibles desde todos los nodos del clúster de K8s.

La CNI de Antrea enviará el tráfico saliente de los pods seleccionados a los nodos de puerta de enlace. Los nodos de puerta de enlace realizan una traducción de direcciones de origen (SNAT) para traducir la IP de origen (IP del pod) a la IP de salida.

Por ejemplo, en el diagrama de flujo de tráfico anterior, el tráfico saliente de pod1 y pod2, que se ejecutan en nodo1, se envía a los nodos de puerta de enlace. El nodo de puerta de enlace traduce las direcciones IP del pod a IP de egress1.

Para obtener más información sobre el recurso de salida, consulte la Guía de salida en el portal de documentación de Antrea.

Los nodos del clúster que se pueden utilizar como nodos de puerta de enlace dependen de la topología de red del nodo, que controla el administrador de red física o el administrador de red de IaaS. Los nodos de puerta de enlace tienen las siguientes dos características:

• La red física permite que los nodos tengan una IP enrutable como IP de origen para acceder a la red externa.
• De forma opcional, se configura un firewall físico en la puerta de enlace física para filtrar el tráfico saliente de los nodos de puerta de enlace.

Tenga en cuenta los ejemplos siguientes:

• Ejemplo 1: supongamos que el clúster de Antrea Kubernetes tiene tres nodos: nodo1, nodo2 y nodo3. Supongamos que nodo1 y nodo2 son nodos especiales en el clúster porque se les asignan dos interfaces de red. Una interfaz para la comunicación del clúster de K8s y otra interfaz para conectarse a la red externa. Al Nodo 3 solo se le asigna una interfaz de red para la comunicación del clúster. En este escenario, solo nodo1 y nodo2 se pueden utilizar como nodos de puerta de enlace.
• Ejemplo 2: supongamos que a los tres nodos del clúster de K8s se les asigna solo una interfaz de red, y que el administrador de red configuró el firewall físico para permitir que solo las direcciones MAC del nodo1 y el nodo2 accedan a Internet. En este escenario, nodo1 y nodo2 se pueden utilizar como nodos de puerta de enlace.
• Ejemplo 3: Supongamos que los tres nodos pueden visitar Internet. El administrador de red configuró un firewall físico en la puerta de enlace física, y el firewall desea filtrar el tráfico de una IP de salida específica. En este escenario, los tres nodos se pueden utilizar como nodos de puerta de enlace.

En el siguiente párrafo se explica una limitación específica de la implementación:

Cualquier host físico o una máquina virtual que se encuentre fuera del clúster de Antrea Kubernetes no se puede utilizar como nodo de puerta de enlace para tunelizar el tráfico saliente del pod. El motivo es que Agente de Antrea mantiene las direcciones IP de salida, y este agente se ejecuta como un pod en cada nodo del clúster de K8s. Por lo tanto, el host físico o una máquina virtual que desee utilizar como nodo de puerta de enlace deberán formar parte del clúster de K8s.

Escenario 2: SNAT a través de nodos

En este escenario, los pods no se seleccionan explícitamente en el archivo de manifiesto de ningún recurso de salida.

El tráfico saliente del pod se enmascara con la IP del nodo y, a continuación, el tráfico se envía a la red de IaaS. Por ejemplo, en el diagrama de flujo de tráfico anterior, una regla SNAT traduce la IP de origen (IP de pod3, IP de pod4) a la IP del nodo2 y, a continuación, el tráfico saliente del pod se envía a la red de IaaS.

Escenario 3: pods enrutables conectados directamente a la red de IaaS

Los pods son enrutables porque se les asignan direcciones IP enrutables en la red subyacente. Por lo general, a los pods se les asignan direcciones IP privadas desde la propiedad PodCIDR, que está configurada en el nodo. Cuando los pods desean acceder a una red externa al clúster de K8s, el tráfico requiere una operación de SNAT para traducir la IP de origen (IP del pod) a una IP enrutable.

Si el clúster de Antrea Kubernetes se implementa en la red de superposición de NSX con Tanzu Kubernetes Grid Service (TKGS), existe un mecanismo para que los nodos del clúster de Tanzu Kubernetes (TKC) soliciten subredes enrutables desde NSX y utilicen esta subred enrutable como propiedad PodCIDR del nodo. A continuación, los pods pueden obtener direcciones IP enrutables. Para obtener más información sobre la configuración de TKC con una red de pods enrutables, consulte la documentación de VMware vSphere with Tanzu.

Si su clúster de Antrea Kubernetes no se implementa en la red de superposición de NSX, el administrador de Kubernetes podrá asegurarse de que se reserve una subred enrutable o un rango de IP enrutable en la red subyacente. El administrador puede configurar la subred o un rango de IP en el archivo de manifiesto del recurso personalizado IPPool. A continuación, la CNI de Antrea podrá asignar direcciones IP enrutables a los pods.

Por ejemplo, en el diagrama de flujo de tráfico anterior, el pod5 que se ejecuta en el nodo5 obtiene una dirección IP enrutable de un recurso personalizado de IPPool.

Para obtener más información sobre el recurso personalizado de IPPool, consulte la Guía de IPAM de Antrea en el portal de documentación de Antrea.

Proteger el tráfico de las máquinas virtuales en NSX a los clústeres de Antrea Kubernetes

Para buscar la correspondencia entre el tráfico de NSX a los clústeres de Antrea Kubernetes, puede agregar grupos genéricos basados en los siguientes tipos de miembros de Kubernetes (recursos) en las reglas de firewall:

• Servicio de Kubernetes
• Entrada de Kubernetes
• Puerta de enlace de Kubernetes
• Grupo de direcciones IP de Antrea

El siguiente diagrama muestra los flujos de tráfico típicos de las máquinas virtuales de la red lógica de NSX hacia el clúster de Antrea Kubernetes.

Como se muestra en este diagrama de flujo del tráfico, para buscar correspondencias del tráfico que entra en el clúster de AntreaKubernetes, se pueden realizar los siguientes escenarios:

Escenario 1: exponer pods al tráfico externo a través de puertos y direcciones IP virtuales

Puede exponer los pods al tráfico externo mediante la implementación de una solución de equilibrador de carga de terceros con estos recursos de Kubernetes nativos:

• Entrada: funciona como un equilibrador de carga de capa 7. Un recurso de entrada proporcionará una dirección IP virtual (VIP) y expondrá algunos puertos (TCP/UDP).
• Puerta de enlace: funciona como un equilibrador de carga de capa 4 y capa 7. Un recurso de puerta de enlace proporcionará una VIP y expondrá algunos puertos (TCP/UDP).
• Servicio de tipo LoadBalancer: funciona como un equilibrador de carga de capa 4. El servicio proporcionará una VIP y expondrá algunos puertos (TCP/UDP).

Nota: Aunque los recursos de entrada y puerta de enlace pueden funcionar como un equilibrador de carga de capa 7, para las reglas de firewall distribuido y las reglas de firewall de puerta de enlace de NSX aparecerán como equilibradores de carga de capa 3 o capa 4 mediante el uso de puertos y direcciones IP para que coincidan con el tráfico entrante.

Escenario 2: exponer pods al tráfico externo a través de puertos y direcciones IP de nodo

• Servicio de Kubernetes de tipo NodePort: activa todos los nodos del clúster de K8s para abrir un puerto en el nodo para cada puerto de servicio. Se puede acceder al servicio a través de la IP y el puerto del nodo. El nodo realiza SNAT y DNAT en el tráfico.
• Servicio de Kubernetes de tipo ClusterIP con la función NodePortLocal habilitada: requiere que se habilite la función NodePortLocal en Agente de Antrea y se agregue una anotación en el archivo de manifiesto del servicio de Kubernetes. La CNI de Antrea reconoce la anotación y abre un puerto para cada pod en el nodo donde se ejecuta el pod. NodePortlLocal evita abrir un puerto en todos los nodos del clúster de K8s, lo que guarda los rangos de puertos disponibles. También evita una operación SNAT y conserva la IP del cliente original.

  Para obtener más información sobre la función NodePortLocal, consulte la Guía de NodePortLocal en el portal de documentación de Antrea.

Escenario 3: exponer pods al tráfico externo a través de direcciones IP de pods enrutables

Antrea admite la asignación de direcciones IP enrutables a los pods mediante la implementación del recurso personalizado de IPPool en el clúster de Kubernetes Antrea. A los pods se les asigna una dirección IP desde este grupo y se los conecta directamente a la red de IaaS.

Redes de IaaS compatibles

Los clústeres de Antrea Kubernetes se pueden implementar en las siguientes plataformas de IaaS:

• Centro de datos local basado en vSphere: como clústeres de Tanzu Kubernetes, que se crean mediante Tanzu Kubernetes Grid Service. Los clústeres se administran mediante Tanzu Kubernetes Grid (TKG) 2.0 y vSphere.
• VMware Cloud: como clústeres de Tanzu Kubernetes administrados por TKG 2.0 y SDDC de VMC.
• Nubes públicas: como clústeres de Kubernetes administrados en las plataformas de nube pública.
• Servidores físicos: como clústeres de Kubernetes en servidores nativos.
• OpenShift:
  • CNI de Antrea implementada en clústeres de OpenShift, y OpenShift se implementa en modo de infraestructura aprovisionada (IPI) del instalador o en modo de infraestructura aprovisionada por el usuario (UPI).
  • Los proveedores de infraestructura pueden ser cualquiera de los siguientes: vSphere, Amazon Web Services (AWS), Azure, OpenStack, Google Cloud Platform (GCP) o nativos.

Importante: La red de IaaS es responsable del tráfico entre clústeres de Antrea Kubernetes y las máquinas virtuales. El tráfico entre diferentes sitios, como centros de datos locales, VMC y nube pública, puede implicar una VPN específica de IaaS. En todos los casos, es posible que la red de IaaS aplique operaciones de SNAT. El administrador de NSX debe asegurarse de que las direcciones IP de origen o destino se puedan enrutar de forma que se puedan utilizar en reglas de firewall para proteger el tráfico entre las máquinas virtuales y los clústeres de Kubernetes.

Enfoques recomendados para aplicar directivas de firewall

Tanto el firewall distribuido como el firewall de puerta de enlace permiten especificar grupos genéricos con tipos de miembros de Kubernetes en los orígenes y los destinos de las reglas de firewall. Por lo tanto, tiene la flexibilidad de decidir si desea hacer referencia a los grupos en el firewall distribuido o el firewall de puerta de enlace.

VMware proporciona la siguiente recomendación:

• Utilice el firewall de puerta de enlace de NSX para permitir o bloquear el tráfico desde los clústeres de Antrea Kubernetes hacia las máquinas virtuales de una red de NSX.

  Este enfoque ayuda a filtrar el tráfico lo antes posible cuando el tráfico entra en la red de superposición de NSX.

• Utilice el firewall distribuido de NSX para permitir o bloquear el tráfico de las máquinas virtuales de una red de NSX para clústeres de Antrea Kubernetes.

  Este enfoque ayuda a filtrar el tráfico lo antes posible cuando el tráfico sale de las máquinas virtuales en una red de superposición de NSX.

Resumen de los tipos de miembros de Kubernetes para su uso en las directivas de firewall

En la siguiente tabla se resumen los tipos de miembros de Kubernetes que se pueden utilizar en grupos genéricos de NSX para que coincidan con el tráfico de las reglas de firewall.

Tipo de miembro	Ámbito	Uso en la directiva de firewall
Clúster de Kubernetes	Clúster	Aparece como una condición AND en los criterios de grupo dinámico para que coincidan con los recursos de clústeres específicos.
Espacio de nombres de Kubernetes	Espacio de nombres	Aparece como una condición AND en los criterios de grupo dinámico para que coincidan con los recursos de espacios de nombres específicos.
Salida de Antrea	Clúster	Hacer coincidir el tráfico saliente de clústeres de Antrea Kubernetes en los que la IP de origen es igual a IP de salida
Grupo de direcciones IP de Antrea	Clúster	Busque correspondencias del tráfico saliente de clústeres de Antrea Kubernetes en los que la IP de origen se encuentra en rangos de IP. Busque correspondencias del tráfico que entra en los clústeres de Antrea Kubernetes donde la IP de destino se encuentra en rangos de IP.
Nodo de Kubernetes	Clúster	Busque correspondencias del tráfico saliente de clústeres de Antrea Kubernetes donde la IP de origen se encuentra entre las direcciones IP del nodo del clúster.
Entrada de Kubernetes	Espacio de nombres	Busque correspondencias del tráfico que entra en los clústeres de Antrea Kubernetes donde la IP de destino se encuentra en las direcciones IP de entrada.
Puerta de enlace de Kubernetes	Espacio de nombres	Busque correspondencias del tráfico que entra en los clústeres de Antrea Kubernetes donde la IP de destino se encuentra en las direcciones IP de puerta de enlace.
Servicio de Kubernetes (type=LoadBalancer)	Espacio de nombres	Busque correspondencias del tráfico que entra en los clústeres de Antrea Kubernetes donde la IP de destino se encuentra en las direcciones IP de LoadBalancer.
Servicio de Kubernetes (type=NodePort)	Espacio de nombres	Busque correspondencias del tráfico que entra en los clústeres de Antrea Kubernetes donde la IP de destino + el puerto se encuentran en las direcciones IP del nodo + el rango de NodePort.
Servicio de Kubernetes (type=ClusterIP)	Espacio de nombres	Ninguno
Servicio de Kubernetes (type=ClusterIP) y la función NodePortLocal habilitados	Espacio de nombres	Busque correspondencias del tráfico que entra en los clústeres de Antrea Kubernetes donde la IP de destino + el puerto se encuentran en las direcciones IP del nodo + el rango de NodePortLocal.