Règle de réseau

Pour définir une règle de réseau pour les charges de travail de machine virtuelle (VM) au niveau de l'espace de noms du projet, utilisez la ressource ProjectNetworkPolicy, une règle de réseau multicluster pour l'appliance Google Distributed Cloud (GDC) isolée. Il vous permet de définir des règles qui autorisent la communication au sein des projets, entre les projets et vers des adresses IP externes.

Pour le trafic au sein d'un projet, GDC applique par défaut une règle de réseau de projet prédéfinie, la règle intra-projet, à chaque projet. Pour activer et contrôler le trafic entre les projets d'une même organisation, vous devez définir des règles inter-projets. Lorsque plusieurs règles sont présentes, GDC combine de manière additive les règles de chaque projet. GDC autorise également le trafic si au moins une des règles correspond.

Demander une autorisation et un accès

Pour effectuer les tâches listées sur cette page, vous devez disposer du rôle Administrateur NetworkPolicy du projet. Demandez à votre administrateur IAM de projet de vous accorder le rôle Administrateur de NetworkPolicy de projet (project-networkpolicy-admin) dans l'espace de noms du projet dans lequel réside la VM.

Trafic intra-projet

Par défaut, les charges de travail de VM dans un espace de noms de projet peuvent communiquer entre elles sans exposer les services au monde extérieur, même si les VM font partie de différents clusters au sein du même projet.

Stratégie de réseau pour le trafic d'Ingress intra-projet

Lorsque vous créez un projet, vous créez une ProjectNetworkPolicy de base par défaut sur le serveur de l'API Management pour autoriser la communication au sein du projet. Cette stratégie autorise le trafic entrant provenant d'autres charges de travail du même projet. Vous pouvez le supprimer, mais soyez prudent, car cela entraînera le refus de la communication entre les charges de travail de conteneur et de projet.

Règle de réseau pour le trafic de sortie intra-projet

Par défaut, aucune action n'est requise de votre part concernant le trafic sortant. En effet, en l'absence de règle de sortie, tout le trafic est autorisé. Toutefois, lorsque vous définissez une seule règle, seul le trafic qu'elle spécifie est autorisé.

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

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-intra-project-egress-traffic
spec:
  policyType: Egress

  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Trafic multiprojets (au sein de l'organisation)

Les charges de travail de VM provenant de différents espaces de noms de projet mais appartenant à la même organisation peuvent communiquer entre elles en appliquant une règle de réseau multiprojet.

Règle de réseau de trafic d'Ingress inter-projets

Pour que les charges de travail d'un projet autorisent les connexions provenant d'autres charges de travail dans un autre projet, vous devez configurer une règle Ingress;entrée pour autoriser l'entrée des charges de travail de l'autre projet.

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. Exécutez la commande suivante pour appliquer la règle :

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

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. Exécutez la commande suivante pour appliquer la règle de réciprocité :

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

Vous avez maintenant autorisé les connexions initiées vers et depuis PROJECT_1 et PROJECT_2.

Utilisez les définitions suivantes pour vos variables.

VariableDéfinition
MANAGEMENT_API_SERVERChemin d'accès kubeconfig du serveur de l'API Management.
PROJECT_1Nom d'un projet GDC correspondant à PROJECT_1 dans l'exemple.
PROJECT_2Nom d'un projet GDC correspondant à PROJECT_2 dans l'exemple.

Règle de réseau pour le trafic de sortie inter-projets

Lorsque vous accordez une stratégie de trafic d'entrée multiprojet pour permettre aux charges de travail d'un projet, PROJECT_1, d'autoriser les connexions à partir des charges de travail d'un autre projet, PROJECT_2, cela 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 de sortie inter-projets.

Trafic inter-organisation

Pour connecter une charge de travail de VM à une destination en dehors de votre projet et située dans une autre organisation, une approbation explicite est requise. Cette approbation est due à la fonctionnalité de prévention de l'exfiltration de données, que GDC active par défaut et qui empêche un projet d'avoir une sortie vers des charges de travail en dehors de l'organisation dans laquelle réside le projet. Les instructions pour ajouter une règle de sortie spécifique et activer l'exfiltration de données sont fournies dans cette section.

Règle de réseau pour le trafic entrant entre organisations

Lorsque vous avez configuré une règle de réseau de sortie multi-organisations, vous n'avez pas besoin d'accorder l'entrée. Le trafic de sortie autorisé de la charge de travail en dehors de votre organisation passe par un équilibreur de charge (EL) et ce trafic de sortie est une traduction d'adresse réseau source (NAT) utilisant une adresse IP que vous avez allouée au projet.

Règle de réseau pour le trafic sortant entre organisations

Pour activer la sortie vers des services en dehors de l'organisation, personnalisez la règle de réseau de votre projet, ProjectNetworkPolicy. Toutefois, comme la prévention de l'exfiltration de données est activée par défaut, votre ProjectNetworkPolicy de sortie personnalisé affiche une erreur de validation dans le champ d'état, et le plan de données l'ignore. Cela est volontaire.

Les charges de travail peuvent sortir lorsque vous autorisez l'exfiltration de données pour un projet donné. Le trafic de sortie que vous autorisez est une traduction d'adresse réseau (NAT) source utilisant une adresse IP bien connue allouée au projet.

Ces instructions vous expliquent comment activer votre règle de sortie personnalisée :

  1. Configurez et appliquez votre propre sortie personnalisée ProjectNetworkPolicy en suivant l'exemple de la CLI kubectl. Appliquez la règle à toutes les charges de travail utilisateur dans PROJECT_1. Elle autorise le trafic sortant vers tous les hôtes de CIDR, qui résident en dehors de l'organisation. Votre première tentative entraîne une erreur d'état nécessaire, ce qui est normal.

  2. Appliquez votre configuration ProjectNetworkPolicy :

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
    apiVersion: networking.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT_1
      name: allow-egress-traffic-to-NAME
    spec:
      policyType: Egress
      subject:
        subjectType: UserWorkload
     egress:
      - to:
        - ipBlock:
            cidr: CIDR
    EOF
    
  3. Lorsque vous avez terminé, vérifiez qu'une erreur de validation s'affiche dans votre état.

  4. Demandez à l'administrateur de désactiver la protection contre l'exfiltration de données. Cela permet d'activer votre configuration tout en empêchant toute autre sortie.

  5. Vérifiez le ProjectNetworkPolicy que vous venez de créer et assurez-vous que l'erreur a disparu du champ de l'état de validation et que l'état Ready est True, ce qui indique que votre règle est en vigueur :

    kubectl --kubeconfig MANAGEMENT_API_SERVER get projectnetworkpolicy
    allow-egress-traffic-to-NAME -n PROJECT_1 -o yaml
    

    Remplacez les variables en utilisant les définitions suivantes.

    VariableDéfinition
    MANAGEMENT_API_SERVERFichier kubeconfig du serveur de l'API Management.
    PROJECT_1Nom du projet GDC.
    CIDRBloc CIDR (Classless Inter-Domain Routing) de la destination autorisée.
    NAMENom associé à la destination.

    Une fois cette règle appliquée, et à condition que vous n'ayez pas défini d'autres règles de sortie, tout autre trafic de sortie est refusé pour PROJECT_1.