Configurer une passerelle NAT de sortie

Avec Anthos clusters on VMware (GKE On-Prem), vous pouvez configurer la traduction d'adresse réseau source (SNAT) afin que certains trafics de sortie de votre cluster d'utilisateur reçoivent 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.

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 réseau Anthos

Cette section s'adresse aux administrateurs de cluster.

Créez un nouveau cluster d'utilisateur avec Anthos Network Gateway activé.

Dans votre fichier de configuration de cluster d'utilisateur, définissez enableDataplaneV2 et enableAnthosNetworkGateway sur true.

enableDataplaneV2: true
...
enableAnthosNetworkGateway: 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 Anthos Network Gateway 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 AnthosNetworkGateway

Cette section s'adresse aux administrateurs de cluster.

Voici un exemple de fichier manifeste pour un objet AnthosNetworkGateway :

kind: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
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-ang.yaml.

Créez l'objet AnthosNetworkGateway :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ang.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
metadata:
  name: alice-paul
spec:
  egress:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  destinationCIDRs:
  - 8.8.8.0/24
  egressSourceIP: 192.168.1.100

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.

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

Problèmes connus

Dupliquer les adresses egressSourceIP

Lorsque vous créez un objet EgressNATGateway, il se peut que l'adresse egressSourceIP que vous spécifiez soit déjà utilisée pour un autre objet EgressNATPolicy. Cela entraînera des conflits de routage du trafic de sortie. Collaborez avec votre équipe de développement pour déterminer les adresses IP flottantes disponibles avant de spécifier l'adresse egressSourceIP.

Modifications apportées aux ressources personnalisées

Les modifications apportées aux ressources personnalisées EgresNATPolicy ne sont pas enregistrées dans les ressources personnalisées Cilium.