Avec Google Distributed Cloud, vous pouvez configurer la traduction d'adresse réseau source (SNAT) afin qu'une partie du trafic sortant de votre cluster d'utilisateur soit attribuée à une adresse IP source prévisible.
Ce document explique comment configurer une passerelle NAT de sortie pour un cluster d'utilisateur.
Introduction
Parfois, des pods s'exécutent dans un cluster d'utilisateur qui doit envoyer des paquets aux composants exécutés dans votre organisation, mais en dehors du cluster. Vous pouvez choisir de concevoir ces composants externes de sorte qu'ils filtrent le trafic réseau entrant en fonction d'un ensemble d'adresses IP sources bien connues.
Voici quelques scénarios :
Vous disposez d'un pare-feu en amont d'une base de données qui n'autorise l'accès que par adresse IP. Par ailleurs, l'équipe qui gère le pare-feu de la base de données est différente de celle qui gère le cluster d'utilisateur.
Les charges de travail de votre cluster d'utilisateur doivent accéder à une API tierce via Internet. Pour des raisons de sécurité, le fournisseur d'API authentifie et autorise le trafic en utilisant l'adresse IP comme identité.
Avec une passerelle NAT de sortie, vous pouvez contrôler avec précision les adresses IP sources utilisées pour le trafic réseau transmis depuis un cluster.
Tarification
L'utilisation de cette fonctionnalité est gratuite pendant l'aperçu.
Fonctionnement d'une passerelle NAT de sortie
Habituellement, lorsqu'un pod envoie un paquet en dehors du cluster, le paquet fait l'objet d'une traduction SNAT avec l'adresse IP du nœud sur lequel le pod est exécuté.
Lorsqu'une passerelle NAT de sortie est en place, vous pouvez spécifier le fait que certains paquets sortants doivent d'abord être envoyés à un nœud de passerelle dédié. L'interface réseau sur le nœud de passerelle est configurée avec deux adresses IP : l'adresse IP principale et une adresse IP source de sortie.
Lorsqu'un paquet a été sélectionné pour utiliser la passerelle NAT de sortie, le paquet quitte le cluster du nœud de passerelle et fait l'objet d'une traduction SNAT avec l'adresse IP source de sortie configurée sur l'interface réseau.
Le schéma suivant illustre le flux du paquet :
Dans le schéma précédent, vous pouvez observer le flux d'un paquet envoyé depuis le pod.
Sur un nœud doté de l'adresse IP 192.168.1.1, un pod doté de l'adresse IP 10.10.10.1 génère un paquet sortant.
Le paquet correspond à une règle de sortie. Il est donc transféré vers le nœud de passerelle.
Le nœud de passerelle modifie l'adresse IP source en 192.168.1.100 et envoie le paquet hors du cluster.
Le trafic retour est renvoyé au nœud de passerelle avec la destination 192.168.1.100.
Le nœud de passerelle utilise conntrack pour modifier l'adresse IP de destination en 10.10.10.1.
Le paquet est traité comme du trafic en cluster, transféré vers le nœud d'origine et renvoyé au pod d'origine.
Personas
Cette rubrique fait référence à deux personas :
Administrateur du cluster. Cette personne crée un cluster d'utilisateur et spécifie les adresses IP flottantes qui seront utilisées par Anthos Network Gateway.
Développeur. Cette personne exécute des charges de travail sur le cluster d'utilisateur et crée des règles de sortie.
Activer la passerelle NAT de sortie
Cette section s'adresse aux administrateurs de cluster.
Pour configurer une passerelle NAT de sortie, utilisez les champs enableDataplaneV2
et advancedNetworking
dans le fichier de configuration du cluster d'utilisateur, puis créez un ou plusieurs objets NetworkGatewayGroup.
Dans le fichier de configuration de votre cluster, définissez les champs suivants sur true
:
enableDataplaneV2: true ... advancedNetworking: true
Créez le cluster d'utilisateur.
Spécifier des adresses IP flottantes
Cette section s'adresse aux administrateurs de cluster.
Choisissez un ensemble d'adresses IP que vous souhaitez utiliser en tant qu'adresses sources de sortie. Ces adresses sont appelées adresses IP flottantes, car Network Gateway Group les attribue, si nécessaire, aux interfaces réseau des nœuds qu'il choisit de définir comme passerelles de sortie.
Les adresses IP flottantes doivent se trouver dans le même sous-réseau que les adresses IP de vos nœuds.
Votre ensemble d'adresses IP flottantes ne doit pas chevaucher l'ensemble d'adresses IP que vous avez spécifié pour vos nœuds.
Supposons par exemple qu'un sous-réseau possède la plage d'adresses 192.168.1.0/24. Supposons également que vous ayez choisi d'utiliser les plages 192.168.1.1 à 192.168.1.99 pour les nœuds. Vous pouvez ensuite utiliser les plages 192.168.1.100 à 192.168.1.104 en tant qu'adresses IP flottantes.
Créer un objet NetworkGatewayGroup
Cette section s'adresse aux administrateurs de cluster.
Voici un exemple de fichier manifeste pour un objet NetworkGatewayGroup :
kind: NetworkGatewayGroup apiVersion: networking.gke.io/v1 metadata: namespace: kube-system name: default spec floatingIPs: - 192.168.1.100 - 192.168.1.101 - 192.168.1.102 - 192.168.1.103 - 192.168.1.104
Remplacez le tableau des floatingIPs
par vos adresses IP flottantes, puis enregistrez le fichier manifeste dans un fichier nommé my-ngg.yaml
.
Créez l'objet NetworkGatewayGroup :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ngg.yaml
Exemple de règle NAT de sortie
Cette section s'adresse aux développeurs.
Voici un exemple de ressource personnalisée EgressNatPolicy :
kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: alice-paul spec: sources: - namespaceSelector: matchLabels: user: alice podSelector: matchLabels: role: frontend - namespaceSelector: matchLabels: user: paul podSelector: matchLabels: role: frontend action: SNAT destinations: - cidr: 8.8.8.0/24 gatewayRef: name: default namespace: kube-system
Dans le fichier manifeste précédent, nous constatons :
Un pod est éligible à la NAT de sortie s'il répond aux exigences suivantes :
Le pod possède le libellé
role: frontend
, et il se trouve dans un espace de noms portant le libelléuser: alice
.Le pod possède le libellé
role: frontend
, et il se trouve dans un espace de noms portant le libelléuser: paul
.
Le trafic depuis un pod éligible vers une adresse comprise dans la plage 8.8.8.0/24 est envoyé à la passerelle NAT de sortie.
La section
gatewayRef
détermine l'adresse IP source de sortie. La ressource personnalisée EgressNATPolicy utilise les valeursgatewayRef.name
etgatewayRef.namespace
pour rechercher un objet NetworkGatewayGroup. La règle utilise l'une des adresses IP flottantes de NetworkGatewayGroup comme adresse IP source pour le trafic de sortie. Si le réseau NetworkGatewayGroup contient plusieurs adresses IP flottantes, la règle utilise la première adresse IP de la listefloatingIPs
et ignore toutes les autres adresses IP. Si la sectiongatewayRef
comporte des champs non valides, l'application de l'objet EgressNATPolicy échoue.
Créer un objet EgressNATPolicy
Créez votre propre fichier manifeste EgressNATPolicy. Définissez metadata.name
sur "my-policy"
.
Enregistrez votre fichier manifeste dans un fichier nommé my-policy.yaml
.
Créez l'objet EgressNatPolicy :
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f my-policy.yaml
Afficher les informations concernant votre règle NAT de sortie
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get egressnatpolicy my-policy --output yaml kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --namespace kube-system --output yaml kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe egressnatpolicy my-policy
Ordre de priorité des opérations
La règle NAT de sortie est compatible avec les API de règle de réseau. La règle de réseau est évaluée avant la règle NAT de sortie. Si une règle de réseau indique de supprimer un paquet, celui-ci est supprimé, quelle que soit la règle NAT de sortie.
Plusieurs règles de sortie
Comme décrit précédemment, chaque règle EgressNATPolicy utilise la première adresse IP de la liste floatingIPs
de la classe NetworkGatewayGroup correspondant à gatewayRef.name
et gatewayRef.namespace
. Si vous créez plusieurs règles et que vous avez l'intention d'utiliser des adresses IP différentes, vous devez créer plusieurs objets NetworkGatewayGroup, puis y faire référence respectivement. Si vous créez plusieurs règles, l'objet gatewayRef
doit être unique pour chaque règle.
Chaque ressource NetworkGatewayGroup
doit contenir des adresses IP flottantes uniques.
Pour configurer plusieurs objets EgressNATPolicy
afin qu'ils utilisent la même adresse IP, utilisez les mêmes valeurs gatewayRef.name
et gatewayRef.namespace
pour les deux.
Pour configurer plusieurs règles de sortie et plusieurs objets de passerelle :
Créez des objets passerelle dans l'espace de noms
kube-system
pour gérer chaque adresse IP flottante. En règle générale, chaque règle de sortie doit avoir un objet passerelle correspondant pour garantir l'allocation de l'adresse IP correcte.Vérifiez ensuite chaque objet passerelle avec
kubectl
pour obtenir l'état d'allocation des adresses IP flottantes:kind: NetworkGatewayGroup apiVersion: networking.gke.io/v1 metadata: namespace: kube-system name: gateway1 spec: floatingIPs: - 192.168.1.100 status: ... floatingIPs: 192.168.1.100: worker1 --- kind: NetworkGatewayGroup apiVersion: networking.gke.io/v1 metadata: namespace: kube-system name: gateway2 spec: floatingIPs: - 192.168.1.101 status: ... floatingIPs: 192.168.1.101: worker2 --- kind: NetworkGatewayGroup apiVersion: networking.gke.io/v1 metadata: namespace: kube-system name: gateway3 spec: floatingIPs: - 192.168.1.102 status: ... floatingIPs: 192.168.1.102: worker1
Créez plusieurs règles faisant référence aux objets de passerelle, telles que
gateway1
, créé à l'étape précédente:kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: egresspolicy1 spec: ... gatewayRef: name: gateway1 namespace: kube-system --- kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: egresspolicy2 spec: ... gatewayRef: name: gateway2 namespace: kube-system --- kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: egresspolicy3 spec: ... gatewayRef: name: gateway3 namespace: kube-system
(Facultatif) Spécifier les nœuds sur lesquels placer les adresses IP flottantes
Les ressources NetworkGatewayGroup
sont compatibles avec les sélecteurs de nœuds. Pour spécifier un sous-ensemble de nœuds pouvant héberger une adresse IP flottante, vous pouvez ajouter le sélecteur de nœuds à l'objet NetworkGatewayGroup
, comme indiqué dans l'exemple suivant:
kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
namespace: cluster-cluster1
name: default
spec:
floatingIPs:
- 192.168.1.100
- 192.168.1.101
- 192.168.1.102
nodeSelector:
node-type: "egressNat"
Le sélecteur de nœuds correspond aux nœuds ayant l'étiquette spécifiée, et seuls ces nœuds sont pris en compte pour l'hébergement d'une adresse IP flottante. Si vous spécifiez plusieurs sélecteurs, leur logique s'additionne. Par conséquent, un nœud doit correspondre à chaque étiquette pour être pris en compte pour héberger une adresse IP flottante. S'il n'y a pas beaucoup de nœuds avec des étiquettes correspondantes, un sélecteur de nœuds peut réduire les qualités de haute disponibilité de l'emplacement des adresses IP flottantes.