Cette page a été traduite par l'API Cloud Translation.

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

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.

Pour appliquer le trafic inter-projets 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.
Pour les règles de sortie du réseau, vous devez également désactiver la protection contre l'exfiltration de données pour le 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 autoriser les connexions aux charges de travail ou aux services de votre projet à partir de charges de travail d'un autre projet de votre organisation, vous devez configurer une règle de pare-feu pour le trafic entrant.

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 dans un autre projet :

Console

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.
Cliquez sur Créer dans la barre d'actions pour commencer à créer une règle de pare-feu.
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 Cible, 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 du 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 de 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.
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.

Pour créer une règle d'entrée réciproque dans l'autre sens, accédez à la console GDC de l'autre projet et répétez la procédure.

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 du fichier kubeconfig pour le 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 depuis PROJECT_1 vers PROJECT_2. Pour ce dernier, vous avez besoin d'une règle réciproque dans le projet PROJECT_2. Appliquer la règle de 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 autoriser les charges de travail d'un projet à accepter les connexions des charges de travail d'un autre projet, cette action accorde également le trafic de retour pour les mêmes flux. Vous n'avez donc pas besoin de règle de réseau de trafic sortant inter-projets dans le projet d'origine.

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 :

Console

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.
Dans la barre d'action, cliquez sur Créer pour créer une règle de pare-feu.
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 Cible, 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 du 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.
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.

Pour créer une règle de sortie réciproque dans l'autre sens, accédez à la console GDC de l'autre projet et répétez la procédure.

API

La stratégie suivante permet aux charges de travail du projet PROJECT_1 d'autoriser les connexions aux charges de travail du projet PROJECT_2. 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-outbound-traffic-to-PROJECT_2
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
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 concernées. Par exemple, app, tier ou role.
SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Par exemple, si SUBJECT_LABEL_KEY est défini sur app et que SUBJECT_LABEL_VALUE est défini sur backend, les charges de travail portant le libellé app: backend reçoivent le trafic.
PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail homologues.
PEER_LABEL_VALUE : valeur associée à PEER_LABEL_KEY.

La commande précédente autorise les connexions sortantes de PROJECT_1 vers PROJECT_2, mais pas les connexions de PROJECT_2 vers PROJECT_1. Pour ce dernier, vous avez besoin d'une règle réciproque dans le projet PROJECT_2. Appliquer la règle de réciprocité :

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

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_2
  name: allow-cross-project-outbound-traffic-from-project-2-to-project-1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_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 concernées. Par exemple, app, tier ou role.
- SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Par exemple, si SUBJECT_LABEL_KEY est app et que SUBJECT_LABEL_VALUE est backend, les charges de travail portant le libellé app: backend envoient le trafic.
- PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail homologues.
- PEER_LABEL_VALUE : valeur associée à PEER_LABEL_KEY.

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

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-project-2-to-project-1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
                ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
EOF
```
Remarque : Les ressources doivent avoir des libellés identiques. Pour que cette règle soit appliquée dans une seule zone, les charges de travail du sujet et du pair doivent avoir le même libellé de zone.

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 concernées. Par exemple, app, tier ou role.
- SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Par exemple, si SUBJECT_LABEL_KEY est défini sur app et que SUBJECT_LABEL_VALUE est défini sur backend, les charges de travail portant le libellé app: backend reçoivent le trafic.
- PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail homologues.
- PEER_LABEL_VALUE : valeur associée à PEER_LABEL_KEY.
- ZONE_SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner la zone du sujet. Par exemple, zone ou region.
- ZONE_SUBJECT_LABEL_VALUE : valeur associée à ZONE_SUBJECT_LABEL_KEY. Il spécifie la zone qui reçoit le trafic. Par exemple, si ZONE_SUBJECT_LABEL_KEY est défini sur zone et que ZONE_SUBJECT_LABEL_VALUE est défini sur us-central1-a, les charges de travail portant le libellé zone: us-central1-a reçoivent le trafic.
- ZONE_PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner la zone associée au pair.
- ZONE_PEER_LABEL_VALUE : valeur associée à ZONE_PEER_LABEL_KEY.

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

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_2
  name: allow-single-zone-cross-project-outbound-traffic-from-project-2-to-project-1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
                ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
EOF
```
Remarque : Les ressources doivent avoir des libellés identiques. Pour que cette règle soit appliquée dans une seule zone, les charges de travail du sujet et du pair doivent avoir le même libellé de zone.

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 concernées. Par exemple, app, tier ou role.
- SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Par exemple, si SUBJECT_LABEL_KEY est app et que SUBJECT_LABEL_VALUE est backend, les charges de travail portant le libellé app: backend envoient le trafic.
- PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail homologues.
- PEER_LABEL_VALUE : valeur associée à PEER_LABEL_KEY.
- ZONE_SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner la zone du sujet. Par exemple, zone ou region.
- ZONE_SUBJECT_LABEL_VALUE : valeur associée à ZONE_SUBJECT_LABEL_KEY. 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 envoient le trafic.
- ZONE_PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner la zone associée au pair.
- ZONE_PEER_LABEL_VALUE : valeur associée à ZONE_PEER_LABEL_KEY.

Créer une règle inter-projets pour les clusters standards

Les clusters standards sont des clusters Kubernetes de portée projet qui offrent un contrôle, une flexibilité et des autorisations d'administrateur de cluster plus importants.

Créer une règle d'entrée inter-projets pour les clusters standards

Pour créer une règle intercluster Ingress entre des clusters standards, 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: STANDARD_CLUSTER_1_PROJECT
  name: allow-ingress-from-standard-cluster-2-to-standard-cluster-1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: STANDARD_CLUSTER_1_NAME
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: SUBJECT_NAMESPACE
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - STANDARD_CLUSTER_2_PROJECT
        workloadSelector:
          labelSelector:
            clusters:
              matchLabels:
                kubernetes.io/metadata.name: STANDARD_CLUSTER_2_NAME
            namespaces:
              matchLabels:
                kubernetes.io/metadata.name: PEER_NAMESPACE
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_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.
STANDARD_CLUSTER_1_PROJECT : nom du projet de cluster standard qui reçoit le trafic.
STANDARD_CLUSTER_2_PROJECT : nom du projet de cluster standard d'où provient le trafic.
STANDARD_CLUSTER_1_NAME : nom du cluster Standard qui reçoit le trafic.
STANDARD_CLUSTER_2_NAME : nom du cluster Standard d'où provient le trafic.
SUBJECT_NAMESPACE : espace de noms du sujet dans le cluster standard.
PEER_NAMESPACE : espace de noms du pair dans le cluster standard.
SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail concernées. Par exemple, app, tier ou role.
SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Par exemple, si SUBJECT_LABEL_KEY est défini sur app et que SUBJECT_LABEL_VALUE est défini sur backend, les charges de travail portant le libellé app: backend reçoivent le trafic.
PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail homologues.
PEER_LABEL_VALUE : valeur associée à PEER_LABEL_KEY.

Pour créer une règle d'entrée intercluster entre des clusters standards et partagés, 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: SHARED_CLUSTER_PROJECT
  name: allow-ingress-from-standard-cluster-to-shared-cluster
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - STANDARD_CLUSTER_PROJECT
        workloadSelector:
          labelSelector:
            clusters:
              matchLabels:
                kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
            namespaces:
              matchLabels:
                kubernetes.io/metadata.name: PEER_NAMESPACE
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_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.
STANDARD_CLUSTER_PROJECT : nom du projet de cluster standard.
SHARED_CLUSTER_PROJECT : nom du projet de cluster partagé.
STANDARD_CLUSTER_NAME : nom du cluster standard.
PEER_NAMESPACE : espace de noms du pair dans le cluster standard.
SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail concernées. Par exemple, app, tier ou role.
SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Par exemple, si SUBJECT_LABEL_KEY est défini sur app et que SUBJECT_LABEL_VALUE est défini sur backend, les charges de travail portant le libellé app: backend reçoivent le trafic.
PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail homologues.
PEER_LABEL_VALUE : valeur associée à PEER_LABEL_KEY.

Créer une règle de sortie inter-projets pour les clusters standards

Pour créer une règle de sortie intercluster entre des clusters standards, 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: STANDARD_CLUSTER_2_PROJECT
  name: allow-egress-from-standard-cluster-2-to-standard-cluster-1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: STANDARD_CLUSTER_2_NAME
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: SUBJECT_NAMESPACE
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - STANDARD_CLUSTER_1_PROJECT
        workloadSelector:
          labelSelector:
            clusters:
              matchLabels:
                kubernetes.io/metadata.name: STANDARD_CLUSTER_1_NAME
            namespaces:
              matchLabels:
                kubernetes.io/metadata.name: PEER_NAMESPACE
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_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.
STANDARD_CLUSTER_1_PROJECT : nom du projet de cluster standard qui reçoit le trafic.
STANDARD_CLUSTER_2_PROJECT : nom du projet de cluster standard d'où provient le trafic.
STANDARD_CLUSTER_1_NAME : nom du cluster Standard qui reçoit le trafic.
STANDARD_CLUSTER_2_NAME : nom du cluster Standard d'où provient le trafic.
SUBJECT_NAMESPACE : espace de noms du sujet dans le cluster standard.
PEER_NAMESPACE : espace de noms du pair dans le cluster standard.
SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail concernées. Par exemple, app, tier ou role.
SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Par exemple, si SUBJECT_LABEL_KEY est app et que SUBJECT_LABEL_VALUE est backend, les charges de travail portant le libellé app: backend envoient le trafic.
PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail homologues.
PEER_LABEL_VALUE : valeur associée à PEER_LABEL_KEY.

Pour créer une règle d'intercluster de sortie entre des clusters standards et partagés, 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: STANDARD_CLUSTER_PROJECT
  name: allow-egress-from-standard-cluster-to-shared-cluster
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: SUBJECT_NAMESPACE
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - SHARED_CLUSTER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_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.
STANDARD_CLUSTER_PROJECT : nom du projet de cluster standard.
SHARED_CLUSTER_PROJECT : nom du projet de cluster partagé.
STANDARD_CLUSTER_NAME : nom du cluster standard.
SUBJECT_NAMESPACE : espace de noms du sujet dans le cluster standard.
SUBJECT_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail concernées. Par exemple, app, tier ou role.
SUBJECT_LABEL_VALUE : valeur associée à SUBJECT_LABEL_KEY. Par exemple, si SUBJECT_LABEL_KEY est app et que SUBJECT_LABEL_VALUE est backend, les charges de travail portant le libellé app: backend envoient le trafic.
PEER_LABEL_KEY : clé du libellé utilisé pour sélectionner les charges de travail homologues.
PEER_LABEL_VALUE : valeur associée à PEER_LABEL_KEY.

Créer des règles de réseau inter-projets Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

Créer une règle inter-projets

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

Console

API

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

Console

API

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

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

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

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

Créer une règle inter-projets pour les clusters standards

Créer une règle d'entrée inter-projets pour les clusters standards

Créer une règle de sortie inter-projets pour les clusters standards

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