Créer des règles de réseau inter-projets

Cette page explique comment configurer des règles de réseau de trafic inter-projets dans Google Distributed Cloud (GDC) air-gapped.

Le trafic inter-projets désigne la communication entre les services et les charges de travail provenant de différents espaces de noms de projet, mais au sein de la même organisation.

Par défaut, les services et les charges de travail d'un projet sont isolés des services et charges de travail externes. Toutefois, les services et les charges de travail provenant de différents espaces de noms de projet et appartenant à la même organisation peuvent communiquer entre eux en appliquant des règles de réseau de trafic inter-projets.

Par défaut, ces règles s'appliquent à toutes les zones du monde. Pour en savoir plus sur les ressources globales dans un univers GDC, consultez Présentation des multizones.

Si l'application du trafic inter-projets est nécessaire dans une seule zone, consultez Créer une stratégie inter-projets au niveau de la charge de travail pour une seule zone.

Avant de commencer

Pour configurer des règles de réseau de trafic multiprojets, vous devez disposer des éléments suivants :

  • Les rôles d'identité et d'accès nécessaires. Pour gérer les règles d'un projet spécifique, vous devez disposer du rôle project-networkpolicy-admin. Pour les environnements multizones dans lesquels vous devez gérer des règles qui s'appliquent à toutes les zones, vous avez besoin du rôle global-project-networkpolicy-admin. Pour en savoir plus, consultez Préparer les rôles et les accès prédéfinis.
  • Un projet existant. Pour en savoir plus, consultez Créer un projet.

Créer une règle inter-projets

Vous pouvez définir des règles de trafic d'entrée ou de sortie entre projets pour gérer la communication entre les projets.

Créer une règle d'entrée inter-projets

Pour que les charges de travail ou les services d'un projet autorisent les connexions provenant d'autres charges de travail d'un autre projet de votre organisation, vous devez configurer une règle de pare-feu d'entrée pour autoriser le trafic entrant des autres charges de travail du projet.

Ce règlement s'applique à toutes les zones de votre organisation.

Suivez les étapes ci-dessous pour créer une règle de pare-feu et autoriser le trafic entrant provenant de charges de travail d'un autre projet :

Console

  1. Dans la console GDC du projet que vous configurez, accédez à Mise en réseau > Pare-feu dans le menu de navigation pour ouvrir la page Pare-feu.
  2. Cliquez sur Créer dans la barre d'actions pour commencer à créer une règle de pare-feu.

  3. Sur la page Détails de la règle de pare-feu, saisissez les informations suivantes :

    1. Dans le champ Nom, saisissez un nom valide pour votre règle de pare-feu.
    2. Dans la section Direction du trafic, sélectionnez Entrée pour autoriser le trafic entrant des charges de travail d'autres projets.
    3. Dans la section Ciblage, sélectionnez l'une des options suivantes :
      • Toutes les charges de travail utilisateur : autorisez les connexions aux charges de travail du projet que vous configurez.
      • Service : indiquez que cette règle de pare-feu cible un service spécifique dans le projet que vous configurez.
    4. Si votre cible est un service de projet, sélectionnez le nom du service dans la liste des services disponibles dans le menu déroulant Service.
    5. Dans la section De, sélectionnez l'une des deux options suivantes :
      • Tous les projets : autorisez les connexions depuis les charges de travail dans tous les projets de la même organisation.
      • Autre projet et Toutes les charges de travail utilisateur : autorisent les connexions depuis les charges de travail d'un autre projet de la même organisation.
    6. Si vous souhaitez transférer des charges de travail uniquement à partir d'un autre projet, sélectionnez un projet auquel vous avez accès dans la liste des projets du menu déroulant ID du projet.
    7. Si votre cible concerne toutes les charges de travail utilisateur, sélectionnez l'une des options suivantes dans la section Protocoles et ports :
      • Autoriser tout : autorise les connexions utilisant n'importe quel protocole ou port.
      • Protocoles et ports spécifiés : autorisez les connexions utilisant uniquement les protocoles et les ports que vous spécifiez dans les champs correspondants de la règle de pare-feu d'entrée.

  4. Sur la page Détails de la règle de pare-feu, cliquez sur Créer.

Vous avez désormais autorisé les connexions depuis les charges de travail d'autres projets de la même organisation. Une fois la règle de pare-feu créée, elle est visible dans un tableau sur la page Pare-feu.

API

La règle suivante permet aux charges de travail du projet PROJECT_1 d'autoriser les connexions des charges de travail du projet PROJECT_2, ainsi que le trafic de retour pour les mêmes flux. Appliquez la règle :

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-inbound-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
EOF

Remplacez GLOBAL_API_SERVER par le chemin d'accès kubeconfig du serveur d'API global. Pour en savoir plus, consultez Serveurs d'API globaux et zonaux. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur d'API, consultez Se connecter pour en savoir plus.

La commande précédente permet à PROJECT_2 d'accéder à PROJECT_1, mais n'autorise pas les connexions initiées à partir de PROJECT_1 vers PROJECT_2. Pour ce dernier, vous avez besoin d'une règle réciproque dans le projet PROJECT_2. Appliquez le règlement sur la réciprocité :

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-inbound-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
EOF

Les connexions vers et depuis PROJECT_1 et PROJECT_2 sont désormais autorisées.

Créer une règle de sortie inter-projets

Lorsque vous accordez une règle de trafic d'entrée inter-projets pour permettre aux charges de travail d'un projet d'autoriser les connexions des charges de travail d'un autre projet, cette action accorde également le trafic de retour pour les mêmes flux. Par conséquent, vous n'avez pas besoin de règle de réseau de trafic sortant inter-projets dans le projet d'origine.

Par exemple, si vous créez une règle autorisant le trafic de PROJECT_1 vers PROJECT_2 et que la protection contre l'exfiltration de données est désactivée, vous devez créer une règle d'entrée dans PROJECT_2 et une règle de sortie dans PROJECT_1. Toutefois, les paquets de réponse sont exclus de l'application des règles. Vous n'avez donc pas besoin de règles supplémentaires.

Suivez les étapes ci-dessous pour créer une règle de pare-feu et autoriser le trafic sortant des charges de travail d'un projet :

  1. Dans la console GDC du projet que vous configurez, accédez à Mise en réseau > Pare-feu dans le menu de navigation pour ouvrir la page Pare-feu.
  2. Cliquez sur Créer dans la barre d'actions pour commencer à créer une règle de pare-feu.

  3. Sur la page Détails de la règle de pare-feu, saisissez les informations suivantes :

    1. Dans le champ Nom, saisissez un nom valide pour votre règle de pare-feu.
    2. Dans la section Sens du trafic, sélectionnez Sortie pour indiquer que cette règle de pare-feu contrôle le trafic sortant.
    3. Dans la section Ciblage, sélectionnez l'une des options suivantes :
      • Toutes les charges de travail utilisateur : autorisez les connexions à partir des charges de travail du projet que vous configurez.
      • Service : indiquez que cette règle de pare-feu cible un service spécifique dans le projet que vous configurez.
    4. Si votre cible est un service de projet, sélectionnez le nom du service dans la liste des services disponibles dans le menu déroulant Service.
    5. Dans la section À, sélectionnez l'une des deux options suivantes :
      • Tous les projets : autorisez les connexions aux charges de travail dans tous les projets de la même organisation.
      • Autre projet et Toutes les charges de travail utilisateur : autorisent les connexions aux charges de travail d'un autre projet de la même organisation.
    6. Si vous souhaitez transférer des charges de travail uniquement vers un autre projet, sélectionnez un projet auquel vous pouvez accéder dans la liste des projets du menu déroulant ID du projet.
    7. Si votre cible concerne toutes les charges de travail utilisateur, sélectionnez l'une des options suivantes dans la section Protocoles et ports :
      • Autoriser tout : autorise les connexions utilisant n'importe quel protocole ou port.
      • Protocoles et ports spécifiés : autorisez les connexions en utilisant uniquement les protocoles et les ports que vous spécifiez dans les champs correspondants de la règle de pare-feu de sortie.

  4. Sur la page Détails de la règle de pare-feu, cliquez sur Créer.

Vous avez désormais autorisé les connexions aux charges de travail d'autres projets au sein de la même organisation. Une fois la règle de pare-feu créée, elle est visible dans un tableau sur la page Pare-feu.

Créer une règle inter-projets au niveau de la charge de travail

Les règles de réseau au niveau de la charge de travail offrent un contrôle précis sur la communication entre les charges de travail individuelles de différents projets. Cette précision permet un contrôle plus strict de l'accès au réseau, ce qui améliore la sécurité et l'utilisation des ressources.

Créer une règle d'entrée inter-projets au niveau de la charge de travail

  • Pour créer une règle inter-projets au niveau de la charge de travail d'entrée, créez et appliquez la ressource personnalisée suivante :

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
 namespace: PROJECT_1
 name: allow-cross-project-inbound-traffic-from-target-to-subject
spec:
 policyType: Ingress
 subject:
   subjectType: UserWorkload
   workloadSelector:
     matchLabels:
       SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
 ingress:
 - from:
   - projectSelector:
       projects:
         matchNames:
         - PROJECT_2
       workloads:
         matchLabels:
           TARGET_LABEL_KEY: TARGET_LABEL_VALUE
EOF

    Remplacez les éléments suivants :

    • GLOBAL_API_SERVER : chemin d'accès au fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Serveurs d'API globaux et zonaux. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur d'API, consultez Se connecter pour en savoir plus.
    • PROJECT_1 : nom du projet qui reçoit le trafic.
    • PROJECT_2 : nom du projet d'où provient le trafic.
    • SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail sources. Par exemple, app, tier ou role.
    • SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Il spécifie les charges de travail qui sont à l'origine du trafic autorisé. Par exemple, si SUBJECT_LABEL_KEY est app et que SUBJECT_LABEL_VALUE est backend, les charges de travail portant le libellé app: backend sont la source de trafic.
    • TARGET_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail de destination.
    • TARGET_LABEL_VALUE : valeur associée à TARGET_LABEL_KEY. Il spécifie les charges de travail qui sont la destination du trafic autorisé.

Créer une règle de sortie inter-projets au niveau de la charge de travail

  • Pour créer une règle de sortie multiprojet au niveau de la charge de travail, créez et appliquez la ressource personnalisée suivante :

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-cross-project-outbound-traffic-to-subject-from-target
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
EOF

    Remplacez les éléments suivants :

    • GLOBAL_API_SERVER : chemin d'accès au fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Serveurs d'API globaux et zonaux. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur d'API, consultez Se connecter pour en savoir plus.
    • PROJECT_1 : nom du projet qui envoie le trafic.
    • PROJECT_2 : nom du projet qui reçoit le trafic.
    • SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail sources. Par exemple, app, tier ou role.
    • SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Il spécifie les charges de travail qui sont à l'origine du trafic autorisé. Par exemple, si SUBJECT_LABEL_KEY est app et que SUBJECT_LABEL_VALUE est backend, les charges de travail portant le libellé app: backend sont la source de trafic.
    • TARGET_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail de destination.
    • TARGET_LABEL_VALUE : valeur associée à TARGET_LABEL_KEY. Il spécifie les charges de travail qui sont la destination du trafic autorisé.

Créer une stratégie inter-projets au niveau de la charge de travail à zone unique

Les règles de réseau au niveau de la charge de travail peuvent appliquer le PNP dans une seule zone. Vous pouvez ajouter des libellés spécifiques aux charges de travail d'une même zone. Cela vous permet de contrôler la communication entre les charges de travail individuelles d'un projet ou de différents projets pour cette zone.

Créer une règle inter-projets au niveau de la charge de travail d'entrée à zone unique

  1. Pour créer une stratégie multiprojet au niveau de la charge de travail Ingress à zone unique, créez et appliquez la ressource personnalisée suivante :

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-inbound-traffic-from-target-to-subject
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
        ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
            ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
EOF

    Remplacez les éléments suivants :

    • GLOBAL_API_SERVER : chemin d'accès au fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Serveurs d'API globaux et zonaux. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur d'API, consultez Se connecter pour en savoir plus.
    • PROJECT_1 : nom du projet qui reçoit le trafic.
    • PROJECT_2 : nom du projet d'où provient le trafic.
    • SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail sources. Par exemple, app, tier ou role.
    • SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Il spécifie les charges de travail qui sont à l'origine du trafic autorisé. Par exemple, si SUBJECT_LABEL_KEY est app et que SUBJECT_LABEL_VALUE est backend, les charges de travail portant le libellé app: backend sont la source de trafic.
    • TARGET_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail de destination.
    • TARGET_LABEL_VALUE : valeur associée à TARGET_LABEL_KEY. Il spécifie les charges de travail qui sont la destination du trafic autorisé.
    • ZONE_SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner la zone source. Par exemple, zone ou region.
    • ZONE_SUBJECT_LABEL_VALUE : valeur associée à ZONE_SUBJECT_LABEL_KEY. Elle indique la zone qui est la source du trafic autorisé. Par exemple, si ZONE_SUBJECT_LABEL_KEY est zone et que ZONE_SUBJECT_LABEL_VALUE est us-central1-a, les charges de travail portant le libellé zone: us-central1-a sont la source de trafic.
    • ZONE_TARGET_LABEL_KEY : clé du libellé utilisé pour sélectionner la zone de destination.
    • ZONE_TARGET_LABEL_VALUE : valeur associée à ZONE_TARGET_LABEL_KEY. Elle spécifie la zone de destination du trafic autorisé.

Créer une règle de sortie inter-projets au niveau de la charge de travail pour une seule zone

  • Pour créer une stratégie multiprojet au niveau de la charge de travail de sortie d'une seule zone, créez et appliquez la ressource personnalisée suivante :

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-outbound-traffic-to-subject-from-target
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
        ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
            ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
EOF

    Remplacez les éléments suivants :

    • GLOBAL_API_SERVER : chemin d'accès au fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Serveurs d'API globaux et zonaux. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur d'API, consultez Se connecter pour en savoir plus.
    • PROJECT_1 : nom du projet qui envoie le trafic.
    • PROJECT_2 : nom du projet qui reçoit le trafic.
    • SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail sources. Par exemple, app, tier ou role.
    • SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Il spécifie les charges de travail qui sont à l'origine du trafic autorisé. Par exemple, si SUBJECT_LABEL_KEY est app et que SUBJECT_LABEL_VALUE est backend, les charges de travail portant le libellé app: backend sont la source de trafic.
    • TARGET_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail de destination.
    • TARGET_LABEL_VALUE : valeur associée à TARGET_LABEL_KEY. Il spécifie les charges de travail qui sont la destination du trafic autorisé.
    • ZONE_SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner la zone source. Par exemple, zone ou region.
    • ZONE_SUBJECT_LABEL_VALUE : valeur associée à ZONE_SUBJECT_LABEL_KEY. Elle indique la zone qui est la source du trafic autorisé. Par exemple, si ZONE_SUBJECT_LABEL_KEY est zone et que ZONE_SUBJECT_LABEL_VALUE est us-central1-a, les charges de travail portant le libellé zone: us-central1-a sont la source de trafic.
    • ZONE_TARGET_LABEL_KEY : clé du libellé utilisé pour sélectionner la zone de destination.
    • ZONE_TARGET_LABEL_VALUE : valeur associée à ZONE_TARGET_LABEL_KEY. Elle spécifie la zone de destination du trafic autorisé.