Créer des règles de réseau intra-projet

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

Les règles de réseau du projet définissent des règles d'entrée ou de sortie. Vous pouvez définir des règles qui autorisent la communication au sein des projets, entre les projets et vers des adresses IP externes.

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 intra-projet est nécessaire dans une seule zone, consultez Créer une règle intra-projet au niveau de la charge de travail pour une seule zone.

Avant de commencer

Pour configurer des règles de réseau de trafic intra-projet, 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 intra-projet

Pour le trafic au sein d'un projet, GDC applique par défaut une stratégie de réseau de projet prédéfinie, la stratégie intra-projet, à chaque projet. Par défaut, les charges de travail d'un espace de noms de projet peuvent communiquer entre elles sans rien exposer aux ressources externes.

Par défaut, aucune règle de sortie n'est appliquée. Le trafic sortant est donc autorisé pour tout le trafic intra-projet. Toutefois, lorsque vous définissez une seule règle de sortie, seul le trafic spécifié par la règle est autorisé.

Remarque : Les règles définies dans cette section s'appliquent aux clusters partagés et standards.

Créer une règle d'entrée intra-projet

Lorsque vous créez un projet, vous créez implicitement une ressource ProjectNetworkPolicy de base par défaut qui permet la communication au sein du projet. Cette règle autorise le trafic entrant provenant d'autres charges de travail du même projet.

Vous pouvez supprimer la règle par défaut, mais sachez que cela entraînera le refus de la communication intra-projet pour tous les services et charges de travail du projet. Pour supprimer la règle, utilisez la commande kubectl delete :

kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT

Vous pouvez rajouter la règle par défaut en appliquant le fichier manifeste suivant :

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: base-policy-allow-intra-project-traffic
spec:
  policyType: Ingress
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
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 : nom de votre projet.

Créer une règle de sortie intra-projet

Lorsque vous désactivez la protection contre l'exfiltration de données et que vous appliquez une règle de sortie ProjectNetworkPolicy au projet, par exemple en empêchant l'accès à une ressource externe, utilisez la règle requise suivante pour autoriser le trafic sortant intra-projet :

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-intra-project-outbound-traffic
spec:
  policyType: Egress
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
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 : nom de votre projet.

Créer une règle intra-projet 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 de la communication entre les charges de travail individuelles d'un projet. 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 intra-projet au niveau de la charge de travail

Lorsque vous créez un projet, vous créez implicitement une ressource ProjectNetworkPolicy de base par défaut qui permet la communication intra-projet entre toutes les charges de travail. Cette règle autorise le trafic entrant provenant d'autres charges de travail du même projet.

Pour créer une règle d'entrée au niveau de la charge de travail dans un projet, vous devez d'abord supprimer la règle de base par défaut. Dans le cas contraire, un comportement inattendu peut se produire.

1. Pour supprimer la règle de base par défaut, exécutez la commande suivante :

   kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
   

2. Pour créer une règle d'entrée intra-projet 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
     name: allow-workload-level-intra-project-inbound-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - 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.
   • PROJECT : nom de votre projet.
   • 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 intra-projet au niveau de la charge de travail

• Pour créer une règle de sortie intra-projet 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
    name: allow-workload-level-intra-project-outbound-traffic
  spec:
    policyType: Egress
    subject:
      subjectType: UserWorkload
      userWorkloadSelector:
        labelSelector:
          workloads
            matchLabels:
              SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
    egress:
    - to:
      - projectSelector:
          projects:
            matchNames:
            - 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.
  • PROJECT : nom de votre projet.
  • 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 règle intra-projet au niveau de la charge de travail pour une seule zone

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 intra-projet au niveau de la charge de travail d'entrée à zone unique

Lorsque vous créez un projet, vous créez implicitement une ressource ProjectNetworkPolicy de base par défaut qui permet la communication intra-projet entre toutes les charges de travail. Cette règle autorise le trafic entrant provenant d'autres charges de travail du même projet.

Pour créer une stratégie intra-projet au niveau de la charge de travail d'entrée à zone unique, vous devez d'abord supprimer la stratégie de base par défaut. Dans le cas contraire, un comportement inattendu peut se produire.

1. Pour supprimer la règle de base par défaut, exécutez la commande suivante :

   kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
   

2. Pour créer une règle de réseau de trafic intra-projet 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
     name: allow-single-zone-intra-project-inbound-traffic
   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
           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 : nom de votre projet.
   • 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. 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 intra-projet au niveau de la charge de travail pour une seule zone

• Pour créer une règle de sortie de niveau charge de travail intra-projet à 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
    name: allow-single-zone-intra-project-outbound-traffic
  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
          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 : nom de votre projet.
  • 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. 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 intra-projet 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. Lorsque vous créez une règle intra-projet, elle est héritée par les clusters standards par défaut. Cette règle autorise toute communication au sein des clusters standards qui résident dans le même projet.

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

Lorsque vous créez un projet, vous créez implicitement une ressource ProjectNetworkPolicy de base par défaut qui permet la communication intra-projet entre toutes les charges de travail. Cette règle autorise le trafic entrant provenant d'autres charges de travail du même projet, ainsi que la communication intracluster entre toutes les charges de travail des clusters standards du projet.

Pour créer une règle d'entrée intra-projet pour les clusters standards, vous devez d'abord supprimer la règle de base par défaut. Dans le cas contraire, un comportement inattendu peut se produire.

1. Pour supprimer la règle de base par défaut, exécutez la commande suivante :

   kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
   

   Vous pouvez rajouter la règle par défaut en appliquant le fichier manifeste suivant :

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: base-policy-allow-intra-project-traffic
   spec:
     policyType: Ingress
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT
   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 : nom de votre projet.

2. Pour créer une règle d'entrée de pod à pod intracluster dans 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_PROJECT
     name: allow-ingress-from-intra-cluster-traffic
   spec:
     policyType: Ingress
     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
     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.
   • STANDARD_CLUSTER_NAME : nom du cluster Standard.
   • 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.

3. Pour créer une stratégie d'entrée de nœud à pod intracluster dans les 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_PROJECT
     name: allow-ingress-from-node-to-pod-traffic
   spec:
     policyType: Ingress
     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
     ingress:
     - from:
       - ipBlocks:
         - cidr: NODE_IP
       ports:
       - protocol: TCP
         port: PORT
   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.
   • STANDARD_CLUSTER_NAME : nom du 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.
   • NODE_IP : adresse IP du nœud.
   • PORT : port sur la charge de travail concernée où le trafic est autorisé.

Créer une règle de sortie intra-projet pour les clusters standards

1. Pour créer une règle de sortie de pod à pod intracluster dans les 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_PROJECT
     name: allow-egress-to-intra-cluster-traffic
   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:
             - 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.
   • STANDARD_CLUSTER_NAME : nom du cluster Standard.
   • 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.
   1. Pour créer une règle de sortie de pod à nœud intracluster dans 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_PROJECT
     name: allow-egress-from-pod-to-node-traffic
   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:
       - ipBlocks:
         - cidr: NODE_IP
       ports:
       - protocol: TCP
         port: PORT
   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.
   • STANDARD_CLUSTER_NAME : nom du 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.
   • NODE_IP : adresse IP du nœud.
   • PORT : port de l'adresse IP du nœud vers lequel le trafic est autorisé.