Configurer une passerelle NAT de sortie

Avec Google Distributed Cloud, vous pouvez configurer la traduction d'adresse réseau source (SNAT) afin que certains trafics de sortie de votre cluster d'utilisateurs reçoivent une adresse IP source prévisible.

Ce document explique comment configurer une passerelle NAT de sortie pour un cluster d'utilisateur.

Attention : Vous ne pouvez pas mettre à niveau un cluster de version 1.8.x ou 1.9.x sur lequel Anthos Network Gateway est activé vers une version ultérieure. Par exemple, vous ne pouvez pas mettre à niveau un cluster de version 1.9.0 sur lequel Anthos Network Gateway est activé vers la version 1.9.x, ni mettre à niveau ce cluster vers la version 1.10. Vous ne pouvez mettre à niveau des clusters sur lesquels Anthos Network Gateway est activé que s'ils ont été créés dans la version 1.10 ou ultérieure. Vous pouvez supprimer un cluster de version 1.8.x ou de version 1.9.x, puis le recréer en suivant les instructions du présent document.

Présentation

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.

Tarifs

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.

1. 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.

2. Le paquet correspond à une règle de sortie. Il est donc transféré vers le nœud de passerelle.

3. Le nœud de passerelle modifie l'adresse IP source en 192.168.1.100 et envoie le paquet hors du cluster.

4. Le trafic retour est renvoyé au nœud de passerelle avec la destination 192.168.1.100.

5. Le nœud de passerelle utilise conntrack pour modifier l'adresse IP de destination en 10.10.10.1.

6. 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 valeurs gatewayRef.name et gatewayRef.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 liste floatingIPs et ignore toutes les autres adresses IP. Si la section gatewayRef 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 gatewayRef.name et gatewayRef.namespace pour les deux.

Remarque : Anthos Network Gateway ne vous permet pas de créer des objets de passerelle contenant des adresses IP dans spec.floatingIPs qui sont déjà utilisées dans des objets de passerelle existants. Cette règle est appliquée par un webhook dans Google Distributed Cloud version 1.15.0 ou ultérieure.

Pour configurer plusieurs règles de sortie et plusieurs objets de passerelle :

1. Créez des objets de 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 de passerelle correspondant pour garantir l'attribution de l'adresse IP appropriée.

   Vérifiez ensuite chaque objet de 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
   

2. Créez plusieurs règles faisant référence aux objets de passerelle, tels que gateway1 qui a été 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 susceptibles d'héberger une adresse IP flottante, vous pouvez ajouter le sélecteur de nœuds à l'objet NetworkGatewayGroup, comme illustré 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 portant le libellé spécifié. 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 est additive. Un nœud doit donc correspondre à chaque libellé pour être considéré comme pouvant héberger une adresse IP flottante. S'il n'y a pas beaucoup de nœuds avec des libellés correspondants, un sélecteur de nœuds peut réduire les qualités de haute disponibilité (HA) du placement d'adresses IP flottantes.