Gérer la règle NAT de sortie par défaut d'un projet

Cette page décrit la configuration NAT de sortie par défaut du projet, désormais obsolète, qui peut être utilisée pour permettre aux charges de travail de se connecter en dehors de l'organisation. Cette page contient également des instructions sur la migration vers la solution recommandée, Cloud NAT.

Présentation

Cette page décrit les actions de connectivité de sortie que vous devez effectuer sur une machine virtuelle (VM) ou un pod d'un projet pour permettre aux charges de travail de sortir de l'organisation à l'aide de l'option de configuration NAT de sortie par défaut du projet (obsolète).

La procédure montre comment ajouter un libellé requis aux déploiements pour activer explicitement le trafic sortant et permettre aux charges de travail de communiquer en dehors de l'organisation.

Par défaut, Google Distributed Cloud (GDC) sous air gap empêche les charges de travail d'un projet de sortir de l'organisation. Les charges de travail peuvent quitter l'organisation si votre administrateur de plate-forme (PA) a désactivé la protection contre l'exfiltration de données pour le projet. Pour ce faire, les AP peuvent ajouter le libellé networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" au projet. En plus de désactiver la protection contre l'exfiltration de données, l'opérateur d'application (AO) doit ajouter le libellé egress.networking.gke.io/enabled: true à la charge de travail du pod pour activer la connectivité de sortie pour ce pod. Lorsque vous attribuez et utilisez une adresse IP connue pour le projet, une traduction d'adresse réseau source (NAT) est effectuée sur le trafic sortant de l'organisation.

Vous pouvez gérer la connectivité de sortie des charges de travail dans un pod ou une VM.

Gérer le trafic sortant des charges de travail dans un pod

Pour configurer des charges de travail dans un pod pour la connectivité sortante, vous devez d'abord vous assurer que la protection contre l'exfiltration de données est désactivée pour le projet. Ensuite, assurez-vous que le libellé egress.networking.gke.io/enabled: true est ajouté au pod. Si vous utilisez une construction de niveau supérieur, comme Deployment ou Daemonset, pour gérer des ensembles de pods, vous devez configurer le libellé de pod dans ces spécifications.

L'exemple suivant montre comment créer un Deployment à partir de son fichier manifeste. Le fichier exemple contient la valeur egress.networking.gke.io/enabled: true dans le champ labels pour activer explicitement le trafic sortant du projet. Ce libellé est ajouté à chaque pod du déploiement et permet aux charges de travail des pods de quitter l'organisation.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  selector:
    matchLabels:
      run: APP_NAME
  template:
    metadata:
      labels: # The labels given to each pod in the deployment, which are used
              # to manage all pods in the deployment.
        run: APP_NAME
        egress.networking.gke.io/enabled: true
    spec: # The pod specification, which defines how each pod runs in the deployment.
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
EOF

Remplacez les éléments suivants :

  • USER_CLUSTER_KUBECONFIG : fichier kubeconfig du cluster d'utilisateur sur lequel vous déployez des charges de travail de conteneur.

  • DEPLOYMENT_NAME : fichier kubeconfig du cluster d'utilisateur sur lequel vous déployez des charges de travail de conteneur.

  • APP_NAME : nom de l'application à exécuter dans le déploiement.

  • NUMBER_OF_REPLICAS : nombre d'objets Pod répliqués gérés par le déploiement.

  • CONTAINER_NAME : nom du conteneur.

  • CONTAINER_IMAGE : nom de l'image du conteneur. Vous devez inclure le chemin d'accès au registre de conteneurs et la version de l'image, par exemple REGISTRY_PATH/hello-app:1.0.

Exemple :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
        egress.networking.gke.io/enabled: true
    spec:
      containers:
      - name: hello-app
        image: REGISTRY_PATH/hello-app:1.0

Gérer le trafic sortant des charges de travail dans une VM

Pour configurer des charges de travail dans une VM pour la connectivité de sortie, vous pouvez utiliser la console GDC pour la configuration de la VM ou créer une ressource VirtualMachineExternalAccess. Pour savoir comment activer l'accès externe à une VM pour le transfert de données, consultez Activer l'accès externe dans la section Se connecter à des VM.

Migrer vers Cloud NAT

Avec la disponibilité de Cloud NAT dans la version 1.15, la configuration NAT de sortie par défaut par projet est obsolète. Nous recommandons aux utilisateurs de migrer leurs configurations de sortie de la configuration NAT de sortie du projet par défaut vers Cloud NAT.

La traduction d'adresse réseau (NAT) de sortie par défaut du projet et Cloud NAT ne sont pas compatibles. En d'autres termes, un point de terminaison de pod ou de VM donné ne peut utiliser qu'un seul des deux. Pour migrer des points de terminaison d'une configuration à l'autre, vous devez les désactiver dans l'une, puis les activer dans l'autre.

Pour commencer votre migration, désactivez l'ancienne configuration des points de terminaison que vous souhaitez migrer. Pour ce faire, il existe deux moyens :

  • Désactiver la passerelle NAT de sortie par défaut du projet pour l'ensemble du projet : désactivez la passerelle NAT de sortie par défaut du projet pour tous les points de terminaison du projet en attribuant le libellé networking.gdc.goog/allocate-egress-ip: "false" au projet.
  • Désactiver la passerelle NAT de sortie par défaut du projet par point de terminaison : désactivez la passerelle NAT de sortie par défaut du projet pour un point de terminaison de pod ou de VM spécifique en supprimant le libellé egress.networking.gke.io/enabled:"true" du pod ou de la VM.

Pour poursuivre la migration, à mesure que chaque point de terminaison est supprimé de la passerelle NAT de sortie par défaut, il peut être ajouté à une passerelle Cloud NAT en ajoutant des libellés au point de terminaison qui correspondent aux sélecteurs de libellés de la passerelle choisie.

Pour savoir comment configurer Cloud NAT, consultez Cloud NAT et les pages suivantes.

Suivi des adresses IP de sortie

Avec la passerelle NAT de sortie par défaut, les adresses IP de sortie utilisées pour le trafic de sortie NAT sont incluses dans l'état du projet. Avec Cloud NAT, l'objet "Project" ne contient aucune adresse IP de sortie. L'utilisateur pourra plutôt lister les adresses IP utilisées par la passerelle Cloud NAT en listant les sous-réseaux qui lui sont attribués.