La couche de mise en réseau virtuelle sur Google Distributed Cloud (GDC) air-gapped régit la connectivité, les pare-feu, la découverte de services, l'équilibrage de charge et l'observabilité entre les machines virtuelles et les pods exécutés dans une organisation GDC.
Modèle de mise en réseau GDC
GDC contient deux niveaux de concepts multitenants : les organisations et les projets. Les projets existent au sein des organisations. Vous déployez toutes les charges de travail virtualisées et conteneurisées dans un projet spécifique d'une organisation.
Mise en réseau des organisations
Chaque organisation dans GDC dispose de son propre réseau virtuel isolé. Le réseau virtuel au sein de l'organisation est un espace IP plat, ce qui signifie que toutes les charges de travail de l'organisation disposent d'une connectivité d'adresse IP directe entre elles. Les règles de réseau de projet vous permettent de contrôler l'accès entre les charges de travail de différents projets de l'organisation.
GDC isole chaque organisation au niveau du réseau de toutes les autres organisations. Les charges de travail d'une organisation n'ont pas de connectivité directe par adresse IP avec les charges de travail d'une autre organisation.
Une organisation possède deux plages d'adresses IP différentes : une plage interne et une plage externe. La plage d'adresses IP externes est accessible depuis l'extérieur de l'organisation, tandis que la plage d'adresses IP internes n'est accessible que depuis l'intérieur de l'organisation. Les charges de travail se voient toujours attribuer une adresse IP de la plage interne de l'organisation, ce qui signifie qu'elles ne sont pas accessibles depuis l'extérieur de l'organisation par défaut. Vous devez activer explicitement le trafic entrant et sortant pour les charges de travail à l'aide des contraintes d'entrée et de sortie décrites dans la section Mise en réseau du projet.
Mise en réseau de projets
Vous déployez toutes les machines virtuelles (VM) et les charges de travail conteneurisées dans un projet. Les projets fournissent une limite de segmentation du réseau au sein de l'organisation.
Les charges de travail d'un même projet peuvent communiquer directement entre elles. Toutefois, la règle de réseau par défaut empêche la communication entre les charges de travail de différents projets. Les Règles de réseau de projet (ProjectNetworkPolicy) vous permettent de configurer les projets de l'organisation qui peuvent communiquer entre eux. Si la règle de réseau du projet l'autorise, les charges de travail de l'organisation peuvent se joindre mutuellement au niveau de la couche réseau L3 à l'aide de leurs adresses IP respectives. Vous devez activer explicitement les contraintes d'entrée et de sortie vers et depuis l'organisation pour chaque charge de travail nécessitant du trafic entrant ou sortant.
Configurer des équilibreurs de charge
Les équilibreurs de charge répartissent le trafic entre les charges de travail de backend de votre application, ce qui garantit la stabilité et la disponibilité. Créez des équilibreurs de charge externes et internes pour les charges de travail de pods et de VM. GDC propose trois méthodes pour configurer les équilibreurs de charge. Pour en savoir plus, consultez Gérer les équilibreurs de charge.
Contraintes d'Ingress
Le mécanisme utilisé pour exposer les charges de travail en dehors de l'organisation diffère selon que la charge de travail est basée sur des VM ou des conteneurs.
Vous exposez les charges de travail basées sur des VM en dehors de l'organisation à l'aide de la fonctionnalité d'accès externe aux VM. Vous devez activer cette fonctionnalité pour chaque VM. Chaque VM reçoit sa propre adresse IP à partir de la plage externe de l'organisation.
En revanche, vous exposez les charges de travail conteneurisées en dehors de l'organisation à l'aide de la fonctionnalité d'équilibreur de charge externe. Vous pouvez créer un équilibreur de charge externe, et GDC attribue une adresse IP externe. Le trafic peut ensuite être équilibré en charge sur un ensemble de charges de travail de pods de backend.
Contraintes de sortie
Vous devez activer explicitement le trafic sortant pour chaque projet et charge de travail afin de communiquer en dehors de l'organisation. L'activation du trafic sortant modifie l'adresse IP des charges de travail en adresse IP externe à l'aide de la traduction d'adresse réseau (NAT, Network Address Translation) lors de la connexion en dehors de l'organisation. Pour en savoir plus sur l'autorisation du trafic sortant, consultez Gérer le trafic sortant d'une organisation.
Modèle d'application des règles de réseau
La posture de sécurité des charges de travail au sein d'une organisation est la combinaison des règles de réseau de projet par défaut et créées par l'utilisateur.
L'application des règles est basée sur les flux de trafic de couche 3 et de couche 4. Un flux décrit une connexion à 5 tuples comme suit :
- Adresse IP source
- Adresse IP de destination
- Port source
- Port de destination
- Protocole, tel que
TCPouUDP
Les règles de réseau appliquent le trafic sortant au niveau du nœud qui héberge la charge de travail source et le trafic entrant lorsque le trafic arrive au niveau du nœud qui héberge la charge de travail de destination. Par conséquent, pour établir une connexion, vous devez autoriser la stratégie à quitter la source pour la destination et à arriver à la destination depuis la source.
Le trafic de réponse, tel que le segment SYN-ACK (synchronize-acknowledge) répondant à un segment SYN, n'est pas soumis à l'application des règles. Par conséquent, le trafic de réponse est toujours autorisé si le trafic d'origine l'est. C'est pourquoi vous n'observez que des délais d'inactivité de la connexion dus à l'application des règles par le client qui initie la connexion. Le trafic refusé est supprimé lors du transfert de données sortantes à partir du nœud source ou du transfert de données entrantes au niveau du nœud de destination. La charge de travail de réception n'observe jamais la connexion.
L'application est basée sur des règles d'autorisation cumulatives. L'application résultante pour une charge de travail est une "correspondance quelconque" pour le flux de trafic par rapport à l'union de toutes les règles appliquées à cette charge de travail. Lorsque plusieurs règles sont présentes, celles appliquées à chaque charge de travail sont combinées de manière additive, ce qui autorise le trafic s'il correspond à au moins l'une des règles. Vous ne disposez pas de règles de refus, mais uniquement de règles d'autorisation.
Lorsqu'une règle de réseau refuse un flux, vous ne recevez pas de paquet de réponse et vous constatez un délai d'expiration de la connexion. Par conséquent, les connexions refusées ou réinitialisées au niveau du protocole, ou les erreurs HTTP, ne sont pas le résultat direct de l'application des règles de mise en réseau.
Pour en savoir plus sur les règles de réseau Kubernetes, consultez https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation.