La couche de mise en réseau virtuelle de l'appliance Google Distributed Cloud (GDC) isolée régit la connectivité, les pare-feu, la détection 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 se compose d'un seul niveau de location : les projets.
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. 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.