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 multilocataires : les organisations et les projets. Les projets existent au sein des organisations, et vous déployez toutes les charges de travail virtualisées et conteneurisées dans un projet particulier au sein d'une organisation.
Mise en réseau de l'organisation
Chaque organisation dans GDC possè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é directe par adresse IP. À l'aide des règles de réseau de projet, vous pouvez 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 ne disposent pas d'une connectivité directe par adresse IP avec les charges de travail d'une autre organisation.
Une organisation comporte 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 du projet
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 réseau au sein de l'organisation.
Les charges de travail d'un 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 de projet l'autorise, les charges de travail de l'organisation peuvent se joindre 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 qui nécessite 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 pod 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 activez 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é sur un ensemble de charges de travail de pod de backend.
Contraintes de sortie
Vous devez activer explicitement le trafic sortant pour chaque projet et chaque 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'adresses réseau (NAT) lors de la connexion en dehors de l'organisation. Pour en savoir plus sur l'autorisation du trafic sortant, consultez Présentation de la NAT.
Modèle d'application des règles de réseau
La stratégie de sécurité des charges de travail au sein d'une organisation est l'union des règles de réseau de projet par défaut et créées par l'utilisateur project network policies.
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
TCP,UDPouIPIP
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 nœud qui héberge la charge de travail de destination. Par conséquent, pour établir une connexion, vous devez autoriser la règle à 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'initiation est autorisé. Pour cette raison, vous n'observez que les délais d'inactivité de la connexion dus à l'application des règles du client qui initie la connexion. Le trafic refusé est ignoré lors du transfert de données sortant à partir du nœud source ou du transfert de données entrant au niveau du nœud de destination. La charge de travail de réception n'observe jamais la connexion.
L'application des règles est basée sur des règles de stratégie basées sur l'autorisation qui sont cumulatives. L'application résultante pour une charge de travail est une "correspondance" 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, les règles appliquées à chaque charge de travail sont combinées de manière cumulative, ce qui autorise le trafic s'il correspond à au moins l'une des règles. Vous n'avez pas de règles de refus, uniquement des 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'inactivité de la connexion. Pour cette raison, les connexions au niveau du protocole refusées ou réinitialisées, 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.