Stratégies de pare-feu pour sécuriser le trafic entre les clusters Kubernetes Antrea et les machines virtuelles dans un réseau NSX

À partir de NSX 4.1, vous pouvez créer des groupes génériques avec des types de membres Kubernetes dans des critères d'appartenance dynamique pour faire correspondre le trafic entrant ou sortant de clusters Antrea Kubernetes.

Vous pouvez ensuite utiliser ces groupes génériques dans des règles de pare-feu distribué ou des règles de pare-feu de passerelle pour sécuriser le trafic entre les machines virtuelles dans l'environnement NSX et les espaces dans des clusters Antrea Kubernetes.

Important : Dans un environnement NSX mutualisé, les ressources de cluster Kubernetes ne sont pas exposées à l'inventaire du projet. Par conséquent, dans un projet, vous ne pouvez pas créer de groupes génériques avec des types de membres Kubernetes dans des critères d'appartenance dynamique. Vous devez créer les groupes dans l'affichage Par défaut (espace par défaut) de NSX, puis les consommer dans les règles de pare-feu distribué ou les règles de pare-feu de passerelle sous l'espace par défaut.

Sécurisation du trafic des clusters Kubernetes Antrea vers les machines virtuelles dans NSX

Pour faire correspondre le trafic entre les clusters Kubernetes Antrea et NSX, vous pouvez ajouter des groupes génériques basés sur les types de membres Kubernetes suivants (ressources) dans les règles de pare-feu :

Nœud Kubernetes
Sortie Antrea
Pool IP Antrea

Le diagramme suivant montre les flux de trafic typiques du cluster Kubernetes Antrea vers les machines virtuelles du réseau logique NSX.

Cette image est expliquée dans le texte qui s'y rapporte.

Comme indiqué dans ce diagramme de flux de trafic, pour faire correspondre le trafic qui quitte le cluster Antrea Kubernetes, les scénarios suivants sont possibles :

Scénario 1 : SNAT via sortie (nœuds de passerelle)

Vous pouvez déployer une ressource de sortie dans votre cluster Kubernetes Antrea. Dans le fichier manifeste de la ressource de sortie, sélectionnez les critères de regroupement des espaces auxquels la ressource de sortie s'applique. Vous pouvez spécifier manuellement l'adresse IP de sortie dans le fichier manifeste ou Antrea CNI peut allouer une adresse IP de sortie à partir d'une ressource personnalisée ExternalIPPool.

Important : Les adresses IP de sortie doivent être routables sur le réseau physique et accessibles à partir de tous les nœuds du cluster K8s.

Antrea CNI envoie le trafic sortant des espaces sélectionnés aux nœuds de passerelle. Les nœuds de passerelle effectuent une traduction d'adresse source (SNAT) pour traduire l'adresse IP source (adresse IP de l'espace) en adresse IP de sortie.

Par exemple, dans le diagramme de flux de trafic précédent, le trafic sortant d'espace1 et espace2, qui s'exécutent sur nœud1, est envoyé aux nœuds de passerelle. Le nœud de passerelle convertit les adresses IP de l'espace en adresse IP de sortie1.

Pour en savoir plus sur la ressource de sortie, reportez-vous au Guide de sortie de https://antrea.io/docs/v1.8.0/docs/egress/ sur le portail de documentation d'Antrea.

Les nœuds de cluster qui peuvent être utilisés comme nœuds de passerelle dépendent de la topologie réseau des nœuds, qui est contrôlée par votre administrateur réseau physique ou l'administrateur réseau IaaS. Les nœuds de passerelle ont les deux caractéristiques suivantes :

Le réseau physique permet aux nœuds de disposer d'une adresse IP routable en tant qu'adresse IP source pour accéder au réseau externe.
Éventuellement, un pare-feu physique sur la passerelle physique est configuré pour filtrer le trafic sortant à partir des nœuds de passerelle.

Prenons les exemples suivants :

Exemple 1 : supposons que votre cluster Kubernetes Antrea dispose de trois nœuds : nœud1, nœud2 et nœud3. Supposons que nœud1 et nœud2 dans le cluster sont des nœuds spéciaux, car deux interfaces réseau leur sont attribuées. Une interface pour la communication du cluster K8s et une autre interface pour la connexion au réseau externe. Une seule interface réseau est attribuée au nœud3 pour la communication du cluster. Dans ce scénario, seuls nœud1 et nœud2 peuvent être utilisés comme nœuds de passerelle.
Exemple 2 : supposons que les trois nœuds du cluster K8s se voient attribuer une seule interface réseau et que l'administrateur réseau a configuré le pare-feu physique pour autoriser uniquement les adresses MAC de nœud1 et nœud2 à accéder à Internet. Dans ce scénario, nœud1 et nœud2 peuvent être utilisés comme nœuds de passerelle.
Exemple 3 : supposons que les trois nœuds peuvent accéder à Internet. L'administrateur réseau a configuré un pare-feu physique sur la passerelle physique et le pare-feu souhaite filtrer le trafic à partir d'une adresse IP de sortie spécifique. Dans ce scénario, les trois nœuds peuvent être utilisés comme nœuds de passerelle.

Le paragraphe suivant explique une limitation spécifique à l'implémentation :

Tout hôte physique ou machine virtuelle qui se trouve en dehors du cluster Kubernetes Antrea ne peut pas être utilisé comme nœud de passerelle pour la tunnelisation du trafic sortant de l'espace. Cela est dû au fait que Agent Antrea conserve les adresses IP de sortie et que cet agent s'exécute en tant qu'espace sur chaque nœud du cluster K8s. Par conséquent, l'hôte physique ou une machine virtuelle que vous souhaitez utiliser comme nœud de passerelle doit faire partie du cluster K8s.

Scénario 2 : SNAT via des nœuds

Dans ce scénario, les espaces ne sont pas explicitement sélectionnés dans le fichier manifeste d'une ressource de sortie.

Le trafic sortant de l'espace est masqué sur l'adresse IP du nœud, puis le trafic est envoyé au réseau IaaS. Par exemple, dans le diagramme de flux de trafic précédent, une règle SNAT traduit l'adresse IP source (adresse IP d'espace3, adresse IP espace4) en adresse IP du nœud2, puis le trafic sortant de l'espace est envoyé au réseau IaaS.

Scénario 3 : espaces routables pontés directement vers le réseau IaaS

Les espaces routables signifient que des adresses IP routables sont attribuées aux espaces sur le réseau de sous-couche. En général, des adresses IP privées sont attribuées aux espaces à partir de la propriété PodCIDR qui est configurée sur le nœud. Lorsque les espaces souhaitent accéder à un réseau externe au cluster K8s, le trafic nécessite une opération SNAT pour traduire l'adresse IP source (adresse IP de l'espace) en adresse IP routable.

Si votre cluster Kubernetes Antrea est déployé sur le réseau de superposition NSX avec le Tanzu Kubernetes Grid Service (TKGS), il existe un mécanisme pour que les nœuds de cluster Tanzu Kubernetes (TKC) puissent demander des sous-réseaux routables à partir de NSX et utiliser ce sous-réseau routable comme propriété PodCIDR du nœud. Ensuite, les espaces peuvent obtenir des adresses IP routables. Pour en savoir plus sur la configuration de TKC avec un réseau d'espaces routables, reportez-vous à la documentation VMware vSphere with Tanzu.

Si votre cluster Kubernetes Antrea n'est pas déployé sur le réseau de superposition NSX, l'administrateur Kubernetes peut s'assurer qu'un sous-réseau routable ou une plage d'adresses IP routables est réservé dans le réseau de sous-couche. L'administrateur peut configurer le sous-réseau ou une plage d'adresses IP dans le fichier manifeste de la ressource personnalisée IPPool. Ensuite, Antrea CNI peut allouer des adresses IP routables aux espaces.

Par exemple, dans le diagramme de flux de trafic précédent, espace5 qui s'exécute sur nœud5 obtient une adresse IP routable à partir d'une ressource personnalisée IPPool.

Pour en savoir plus sur la ressource personnalisée IPPool, reportez-vous au Antrea IPAM Guide sur le portail de documentation Antrea.

Sécurisation du trafic des machines virtuelles dans NSX vers les clusters Kubernetes Antrea

Pour faire correspondre le trafic entre NSX et des clusters Antrea Kubernetes, vous pouvez ajouter des groupes génériques basés sur les types de membres Kubernetes suivants (ressources) dans les règles de pare-feu :

Service Kubernetes
Entrée Kubernetes
Passerelle Kubernetes
Pool IP Antrea

Le diagramme suivant montre les flux de trafic typiques des machines virtuelles du réseau logique NSX vers le cluster Kubernetes Antrea.

Cette image est décrite dans le texte qui s'y rapporte.

Comme indiqué dans ce diagramme de flux de trafic, pour faire correspondre le trafic entrant dans le cluster Antrea Kubernetes, les scénarios suivants sont possibles :

Scénario 1 : exposer les espaces au trafic externe via l'adresse IP virtuelle et les ports

Vous pouvez exposer des espaces au trafic externe en implémentant une solution d'équilibreur de charge tierce avec ces ressources Kubernetes natives :

Entrée : elle fonctionne comme un équilibreur de charge de couche 7. Une ressource d'entrée fournit une adresse IP virtuelle (VIP) et expose certains ports (TCP/UDP).
Passerelle : elle fonctionne comme un équilibreur de charge de couche 4 et de couche 7. Une ressource de passerelle fournit une adresse IP virtuelle et expose certains ports (TCP/UDP).
Service de type LoadBalancer : il fonctionne comme un équilibreur de charge de couche 4. Le service fournit une adresse IP virtuelle et expose certains ports (TCP/UDP).

Note : Bien que les ressources d'entrée et de passerelle puissent fonctionner comme un équilibreur de charge de couche 7, pour les règles de pare-feu distribué et les règles de pare-feu de passerelle dans NSX, elles s'affichent comme un équilibreur de charge de couche 3 ou de couche 4 en utilisant des adresses IP et des ports pour correspondre au trafic entrant.

Scénario 2 : exposer les espaces au trafic externe via l'adresse IP et les ports du nœud

Service Kubernetes de type NodePort : il déclenche tous les nœuds du cluster K8s pour ouvrir un port sur le nœud pour chaque port de service. Le service devient accessible via l'adresse IP et le port du nœud. Le nœud exécute SNAT et DNAT sur le trafic.
Service Kubernetes de type ClusterIP avec la fonctionnalité NodePortLocal activée : vous devez activer la fonctionnalité NodePortLocal sur Agent Antrea et ajouter une annotation dans le fichier manifeste du service Kubernetes. Antrea CNI reconnaît l'annotation et ouvre un port pour chaque espace sur le nœud sur lequel l'espace s'exécute. NodePortlLocal évite d'ouvrir un port sur tous les nœuds du cluster K8s. Cela permet d'enregistrer les plages de ports disponibles. Il évite également une opération SNAT et conserve l'adresse IP du client d'origine.
Pour en savoir plus sur la fonctionnalité NodePortLocal, reportez-vous au NodePortLocal Guide sur le portail de documentation d'Antrea.

Scénario 3 : exposer les espaces au trafic externe via des adresses IP d'espace routables

Antrea prend en charge l'attribution d'adresses IP routables à des espaces en déployant la ressource personnalisée IPPool dans votre cluster Kubernetes Antrea. Les espaces se voient allouer une adresse IP à partir de ce pool et ils sont directement pontés sur le réseau IaaS.

Réseaux IaaS pris en charge

Les clusters Kubernetes Antrea peuvent être déployés sur les plates-formes IaaS suivantes :

Centre de données sur site vSphere : en tant que clusters Tanzu Kubernetes, qui sont créés à l'aide de Tanzu Kubernetes Grid Service. Les clusters sont gérés par Tanzu Kubernetes Grid (TKG) 2.0 et vSphere.
VMware Cloud : en tant que clusters Tanzu Kubernetes gérés par TKG 2.0 et VMC SDDC.
Clouds publics : en tant que clusters Kubernetes gérés sur les plates-formes de cloud public.
Serveurs physiques : en tant que clusters Kubernetes sur des serveurs bare-metal.
OpenShift :
- Antrea CNI déployé dans les clusters OpenShift, et OpenShift est déployé en mode IPI (Installer provisioned infrastructure) ou en mode UPI (User Provisioned Infrastructure).
- Les fournisseurs d'infrastructure peuvent être l'un des suivants : vSphere, Amazon Web Services (AWS), Azure, OpenStack, Google Cloud Platform (GCP), bare metal.

Important : Le réseau IaaS est responsable du trafic entre les clusters Kubernetes Antrea et les machines virtuelles. Le trafic entre différents sites, tels que les centres de données sur site, VMC et le cloud public peut impliquer un VPN spécifique à IaaS. Dans tous les cas, des opérations SNAT peuvent être appliquées par le réseau IaaS. L'administrateur NSX doit s'assurer que les adresses IP source ou de destination sont routables afin qu'elles puissent être utilisées dans des règles de pare-feu pour protéger le trafic entre les machines virtuelles et les clusters Kubernetes.

Approches recommandées pour appliquer des stratégies de pare-feu

Le pare-feu distribué et le pare-feu de passerelle vous permettent de spécifier des groupes génériques avec des types de membres Kubernetes dans les sources et les destinations des règles de pare-feu. Par conséquent, vous avez la possibilité de décider s'il convient de référencer les groupes dans le pare-feu distribué ou dans le pare-feu de passerelle.

VMware fournit la recommandation suivante :

Utilisez le pare-feu de passerelle NSX pour autoriser ou bloquer le trafic depuis des clusters Kubernetes Antrea vers des machines virtuelles dans un réseau NSX.
Cette approche vous permet de filtrer le trafic le plus tôt possible lorsque le trafic entre dans le réseau de superposition NSX.
Utilisez le pare-feu distribué NSX pour autoriser ou bloquer le trafic provenant des machines virtuelles d'un réseau NSX vers des clusters Kubernetes Antrea.
Cette approche vous permet de filtrer le trafic le plus tôt possible lorsqu'il laisse les machines virtuelles dans un réseau de superposition NSX.

Résumé des types de membres Kubernetes pour l'utilisation dans les stratégies de pare-feu

Le tableau suivant récapitule les types de membres Kubernetes que vous pouvez utiliser dans des groupes génériques NSX pour faire correspondre le trafic dans les règles de pare-feu.

Type de membre	Portée	Utilisation dans la stratégie de pare-feu
Cluster Kubernetes	Cluster	S'affiche sous la forme d'une condition AND dans les critères de groupe dynamique pour faire correspondre les ressources provenant de clusters spécifiques.
Espace de noms Kubernetes	Espace de noms	S'affiche sous la forme d'une condition AND dans les critères de groupe dynamique pour faire correspondre des ressources provenant d'espaces de noms spécifiques.
Sortie Antrea	Cluster	Faire correspondre le trafic sortant des clusters Antrea Kubernetes où adresse IP source = adresse IP de sortie
Pool IP Antrea	Cluster	Faire correspondre le trafic sortant des clusters Antrea Kubernetes où l'adresse IP source se trouve dans des plages d'adresses IP. Faire correspondre le trafic entrant dans des clusters Kubernetes Antrea où l'adresse IP de destination se trouve dans des plages d'adresses IP.
Nœud Kubernetes	Cluster	Faire correspondre le trafic sortant des clusters Antrea Kubernetes où l'adresse IP source fait partie des adresses IP du nœud de cluster.
Entrée Kubernetes	Espace de noms	Faire correspondre le trafic entrant dans les clusters Kubernetes Antrea où l'adresse IP de destination se trouve dans les adresses IP d'entrée.
Passerelle Kubernetes	Espace de noms	Faire correspondre le trafic entrant dans les clusters Kubernetes Antrea où l'adresse IP de destination se trouve dans les adresses IP de la passerelle.
Service Kubernetes (type=LoadBalancer)	Espace de noms	Faire correspondre le trafic entrant dans les clusters Kubernetes Antrea où l'adresse IP de destination se trouve dans les adresses IP LoadBalancer.
Service Kubernetes (type=NodePort)	Espace de noms	Faire correspondre le trafic entrant dans les clusters Kubernetes Antrea où l'adresse IP de destination + le port se trouvent dans les adresses IP du nœud + la plage NodePort.
Service Kubernetes (type=ClusterIP)	Espace de noms	Aucun
Service Kubernetes (type=ClusterIP) et fonctionnalité NodePortLocal activés	Espace de noms	Faire correspondre le trafic entrant dans les clusters Kubernetes Antrea où l'adresse IP de destination + le port se trouvent dans les adresses IP du nœud + plage NodePortLocal.