Aperçu

Cette page présente les règles de réseau de projet dans Google Distributed Cloud (GDC) air gap.

Les règles de réseau de projet définissent des règles d'entrée ou de sortie. Contrairement aux règles de réseau Kubernetes, vous ne pouvez spécifier qu'un seul type de règle pour une règle. Chaque règle d'une stratégie peut être configurée avec l'action "Autoriser" (par défaut) ou "Refuser".

Pour le trafic au sein d'un projet, GDC applique à chaque projet une règle de réseau de projet prédéfinie, la règle intra-projet par défaut.

Les services et les charges de travail d'un projet sont isolés par défaut des services et des charges de travail externes. Toutefois, les services et les charges de travail de différents espaces de noms de projet et au sein de la même organisation peuvent communiquer entre eux en appliquant des règles de réseau de trafic interprojets.

De même, la connexion de services et de charges de travail à une destination située en dehors de votre projet dans une autre organisation nécessite une approbation explicite. Vous devez désactiver la protection contre l'exfiltration de données pour autoriser le trafic externe à l'organisation.

Les règles de pare-feu d'Ingress et de sortie sont les principaux composants des règles de réseau de projet. Elles déterminent les types de trafic autorisés ou refusés vers et depuis votre réseau. Pour définir des règles de pare-feu pour l'espace de noms de votre projet dans GDC, utilisez la console GDC.

Sécurité et connectivité

Par défaut, les services et les charges de travail d'un projet sont isolés au sein de ce projet. Ils ne peuvent pas communiquer avec des services et des charges de travail externes sans configurer de règle de réseau.

Pour définir une règle de réseau pour l'espace de noms de votre projet dans GDC, utilisez la ressource ProjectNetworkPolicy. Cette ressource vous permet de définir des règles qui autorisent la communication au sein des projets, entre les projets, vers des adresses IP externes et à partir d'adresses IP externes. De plus, vous ne pouvez transférer des charges de travail hors d'un projet que si vous désactivez la protection contre l'exfiltration de données pour ce projet.

Les règles de réseau de projet GDC sont cumulatives. La mesure d'application qui en résulte pour une charge de travail est une correspondance any pour le flux de trafic par rapport à l'union de toutes les règles appliquées à cette charge de travail. Lorsque plusieurs règles sont présentes, les règles de chaque stratégie sont combinées de manière additive, ce qui autorise le trafic s'il correspond à au moins une des règles.

Les règles Deny explicites sont absolument prioritaires sur les règles Allow. Si un flux de trafic correspond à une règle Deny, il est supprimé, même s'il est autorisé par une autre règle ou par les règles par défaut de la plate-forme.

De plus, après avoir appliqué une seule règle qui sélectionne une charge de travail, tout le trafic que vous ne spécifiez pas est refusé (mode de refus par défaut). Par conséquent, lorsque vous appliquez une ou plusieurs règles qui sélectionnent une charge de travail comme sujet, seul le trafic explicitement autorisé (et non explicitement refusé) est autorisé.

Lorsque vous utilisez une adresse IP connue que vous allouez au projet, elle effectue une traduction d'adresse réseau (NAT) source sur le trafic sortant de l'organisation.

Règle intra-projet par défaut

Lorsque vous créez un projet, GDC crée automatiquement une règle de réseau de projet globale nommée base-policy-allow-intra-project-traffic dans l'espace de noms du projet. Cette règle par défaut effectue les opérations suivantes :

  • Sélectionne toutes les charges de travail utilisateur du projet comme sujet.
  • Autorise le trafic entrant vers ces charges de travail à partir de toutes les charges de travail du même projet, sur tous les ports.
  • N'autorise pas le trafic entrant provenant d'autres projets ou de l'extérieur de l'organisation.

GDC ne crée la règle par défaut qu'une seule fois, lors de la création du projet. Si vous modifiez ou supprimez la règle, GDC ne la restaure pas. GDC propage la règle à chaque cluster du projet en tant que règle de réseau nommée g-base-policy-allow-intra-project-traffic. Le champ status.zones[].replicaStatus.propagatedName de la stratégie affiche ce nom.

Pour afficher la stratégie par défaut, exécutez la commande suivante :

kubectl --kubeconfig GLOBAL_API_SERVER get projectnetworkpolicy \
    base-policy-allow-intra-project-traffic -n PROJECT -o yaml

Remplacez les éléments suivants :

  • GLOBAL_API_SERVER : chemin d'accès du fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Serveurs d'API globaux et zonaux.
  • PROJECT : nom de votre projet.

Si la commande renvoie une erreur NotFound, cela signifie que la règle par défaut a été supprimée. Pour l'ajouter à nouveau, consultez Créer une règle d'entrée intra-projet.

La stratégie par défaut est combinée aux stratégies que vous créez comme suit :

  • Entrée : les charges de travail sont isolées des autres projets et de l'extérieur de l'organisation par défaut, que la règle par défaut existe ou non. Les règles d'Ingress que vous créez ajoutent des sources autorisées, telles que d'autres projets ou des blocs CIDR externes. Tant que la stratégie par défaut existe, vous n'avez pas besoin de répéter la règle intra-projet dans vos propres stratégies d'entrée.
  • Entrée intra-projet au niveau de la charge de travail : tant que la règle par défaut existe, toutes les charges de travail du projet peuvent communiquer entre elles sur tous les ports. Une règle d'entrée intra-projet au niveau de la charge de travail qui utilise l'action Allow ne limite pas ce trafic tant que vous ne supprimez pas ou ne modifiez pas la règle par défaut. Pour éviter toute interruption, appliquez vos règles au niveau de la charge de travail et vérifiez qu'elles sont prêtes avant de supprimer la règle par défaut. Pour bloquer un trafic intra-projet spécifique tout en conservant la stratégie par défaut, vous pouvez utiliser une règle de refus explicite, qui est une fonctionnalité en version preview. Pour en savoir plus, consultez Créer une règle intra-projet au niveau de la charge de travail d'entrée.
  • Sortie : par défaut, un projet ne dispose d'aucune règle de sortie. Le trafic sortant n'est pas limité au sein de l'organisation, mais la protection contre l'exfiltration de données (activée par défaut) bloque le trafic qui quitte l'organisation. Les règles de sortie ne prennent effet qu'après la désactivation de la protection contre l'exfiltration de données pour le projet. Lorsque la protection contre l'exfiltration de données est activée, les serveurs d'API zonaux rejettent les règles de sortie, et les règles de sortie globales ne sont pas prêtes.

Règles de réseau de projet globales

Vous pouvez créer des règles de réseau de projet globales. Le champ d'application des règles de réseau de projet globales s'étend à l'ensemble d'un univers GDC. Chaque univers GDC peut être constitué de plusieurs zones GDC organisées en régions interconnectées et partageant un plan de contrôle. Par exemple, un univers composé de deux régions comportant chacune trois zones peut se présenter comme suit : us-virginia1-a, us-virginia1-b, us-virginia1-c et eu-ams1-a, eu-ams1-b, eu-ams1-c.

Le champ d'application des règles de réseau de projet zonales est limité aux zones spécifiées au moment de la création. Chaque zone est un domaine de sinistre indépendant. Une zone gère l'infrastructure, les services, les API et les outils qui utilisent un plan de contrôle local.

Pour en savoir plus sur les ressources globales dans un univers GDC, consultez Présentation de la multizone.

Vous pouvez créer des règles de réseau de projet globales à l'aide de l'API Networking Kubernetes Resource Model (KRM). Utilisez la version d'API networking.global.gdc.goog pour créer des ressources globales.

Vous pouvez créer des règles de réseau de projet zonales à l'aide de l'API KRM ou de la console GDC. Utilisez la version networking.gdc.goog de l'API pour créer des ressources zonales.

Règles de réseau "Tout autoriser"

Vous pouvez créer des règles de réseau "Tout autoriser" pour établir des règles d'accès par défaut étendues pour un projet.

Vous pouvez configurer les types de règles de réseau "tout autoriser" suivants :

  • Règle de réseau "allow-all" : autorise le trafic vers et depuis n'importe quelle source, y compris d'autres projets et des adresses IP externes.
  • Règle de réseau allow-all-external : autorise le trafic vers et depuis des adresses IP externes à l'organisation.
  • Règle de réseau "Autoriser tous les projets" : autorise le trafic vers et depuis tous les projets de l'organisation.

Pour en savoir plus, consultez Créer des règles de réseau autorisant tout le trafic.

Règles de réseau de refus explicite

Vous pouvez configurer des règles de refus explicites dans les règles de réseau de projet pour limiter la connectivité entre des projets ou des blocs CIDR spécifiés.

Principales caractéristiques et contraintes des règles de refus :

  • Priorité : les règles de refus ont une priorité absolue sur les règles d'autorisation (y compris les règles de plate-forme de base).
  • Règles de sécurité de sortie : pour éviter de bloquer accidentellement le trafic d'infrastructure critique, les règles de refus de sortie excluent automatiquement les espaces de noms système et hors projet.
  • Restriction de pair : pour garantir une configuration sécurisée, les règles de refus d'entrée doivent spécifier explicitement un pair source dans le champ from, et les règles de refus de sortie doivent spécifier explicitement un pair de destination dans le champ to. Vous ne pouvez pas sélectionner toutes les sources ou destinations en laissant le champ de pair vide. Il n'est pas autorisé de laisser le champ "peer" vide, et la règle sera refusée.
  • Pas de refus de sortie avec la protection contre l'exfiltration de données : vous ne pouvez pas configurer de règles de refus de sortie lorsque la protection contre l'exfiltration de données est activée pour le projet.

Pour en savoir plus, consultez Créer des règles de réseau de refus explicite.

Règles de réseau au niveau de la charge de travail

Vous pouvez créer des règles de réseau au niveau de la charge de travail pour définir un contrôle ultraprécis des accès pour des VM et des pods individuels au sein d'un projet. Ces règles agissent comme des pare-feu pour vos charges de travail, en contrôlant le flux de trafic en fonction des étiquettes pour renforcer la sécurité et isoler les applications. Cette précision permet de contrôler plus strictement les charges de travail qui peuvent communiquer entre elles au sein des projets et entre eux.

Les règles de réseau au niveau de la charge de travail permettent également d'appliquer des règles de réseau de pod dans une seule zone.

Pour en savoir plus, consultez Créer une règle intra-projet au niveau de la charge de travail et Créer une règle inter-projets au niveau de la charge de travail.

Structure et validation des règles

Dans une ressource ProjectNetworkPolicy, les sélecteurs de libellés de charge de travail sont imbriqués sur plusieurs niveaux. La règle d'entrée suivante indique l'emplacement correct de chaque sélecteur :

apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-frontend-to-backend
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            app: backend
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PEER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: frontend
    ports:
    - protocol: TCP
      port: 8080

Remplacez les éléments suivants :

  • PROJECT : nom de votre projet.
  • PEER_PROJECT : nom du projet contenant les charges de travail clientes.

Cette règle permet aux charges de travail étiquetées app: frontend dans PEER_PROJECT de se connecter aux charges de travail étiquetées app: backend dans votre projet sur le port TCP 8080.

Lorsque vous rédigez une règle, respectez les règles suivantes :

  • Définissez toujours explicitement spec.policyType sur Ingress ou Egress. Une règle Ingress ne peut contenir que des règles ingress avec des pairs from, et une règle Egress ne peut contenir que des règles egress avec des pairs to. Si vous omettez policyType, la règle est définie par défaut sur Ingress, et le serveur d'API rejette une règle qui ne contient que des règles egress.
  • Pour sélectionner des charges de travail par étiquette, utilisez spec.subject.userWorkloadSelector.labelSelector.workloads. Si vous omettez userWorkloadSelector, la règle s'applique à toutes les charges de travail utilisateur du projet.
  • Ne placez pas les sélecteurs d'étiquettes directement sous spec.subject. Par défaut, kubectl rejette les champs tels que spec.subject.matchLabels avec un message strict decoding error: unknown field.
  • Pour sélectionner des charges de travail de pairs par libellé, utilisez projectSelector.workloadSelector.labelSelector.workloads dans une entrée from ou to.
  • Si les charges de travail du sujet ou du pair sont des VM, ajoutez le préfixe user-label.gpc.gke.io/ à leurs clés d'étiquette. Par exemple, utilisez user-label.gpc.gke.io/app: backend.
  • La règle intra-projet par défaut créée automatiquement et certaines règles existantes utilisent le champ spec.subject.workloadSelector obsolète, qui accepte directement un sélecteur d'étiquette. Utilisez userWorkloadSelector dans les nouvelles règles.

Pour valider une règle par rapport au serveur d'API global sans l'appliquer, exécutez un dry run côté serveur :

kubectl --kubeconfig GLOBAL_API_SERVER apply --dry-run=server \
    --validate=strict -f POLICY_FILE

La simulation signale les mêmes erreurs de schéma et de validation qu'une commande kubectl apply réelle, comme un champ inconnu ou une règle egress dans une stratégie Ingress, mais ne crée ni ne modifie la stratégie. La simulation nécessite les mêmes autorisations que l'application de la règle. Une simulation réussie ne confirme pas que la règle est appliquée. Après avoir appliqué la règle, vérifiez qu'elle est prête.

Pour lister les champs acceptés par votre serveur d'API global, exécutez la commande suivante :

kubectl --kubeconfig GLOBAL_API_SERVER explain projectnetworkpolicy.spec \
    --api-version=networking.global.gdc.goog/v1 --recursive

Remplacez les éléments suivants :

  • GLOBAL_API_SERVER : chemin d'accès du fichier kubeconfig du serveur d'API global.
  • POLICY_FILE : chemin d'accès à votre fichier manifeste ProjectNetworkPolicy.

Préparer les rôles prédéfinis et l'accès

Pour configurer des règles de réseau de projet, vous devez disposer des rôles d'identité et d'accès nécessaires :

  • Administrateur de règles de réseau de projet : dispose d'autorisations d'écriture sur toutes les ressources PNP multizones dans l'espace de noms du projet global. Demandez à l'administrateur IAM de votre organisation de vous attribuer le rôle global-project-networkpolicy-admin. Pour en savoir plus, consultez Descriptions des rôles prédéfinis.

Cibler les nœuds de cluster à l'aide de blocs d'adresses IP

Vous pouvez utiliser le champ ipBlocks dans une ressource ProjectNetworkPolicy pour spécifier des adresses IP de nœuds individuels ou des plages CIDR de nœuds, et contrôler le trafic entre les pods et des nœuds de cluster spécifiques (par exemple, en autorisant l'entrée des nœuds du plan de contrôle vers un pod de webhook personnalisé, ou en limitant la sortie des pods vers les nœuds du plan de contrôle). Pour obtenir des instructions, consultez Créer une règle intra-projet pour les clusters standards.

Considérations liées au scaling

Lorsque vous configurez des règles de réseau de projet pour cibler des nœuds spécifiques ou que vous utilisez de larges plages CIDR, vos choix de configuration de règles peuvent affecter l'évolutivité et les performances :

  • Comportement de 0.0.0.0/0 : l'utilisation d'une plage CIDR étendue telle que 0.0.0.0/0 dans une règle ipBlocks correspond à tous les nœuds du cluster, en plus des adresses IP externes.
  • Évolutivité : une identité CIDR unique est attribuée à chaque nœud du cluster. Chaque point de terminaison de charge de travail (VM ou pod) dispose d'une table de règles interne qui stocke ses règles réseau. Dans les grands clusters, les règles ipBlocks larges telles que 0.0.0.0/0 augmentent l'utilisation de la table de règles proportionnellement au nombre de nœuds, car le système doit créer des entrées pour chaque identité CIDR de nœud unique.
  • Avertissement : Évitez d'utiliser des plages CIDR trop larges dans les règles ipBlocks si vous avez un nombre élevé de nœuds ou de nombreuses règles complexes, car vous risquez d'atteindre la limite de la table de règles pour un point de terminaison. Si un point de terminaison atteint cette limite, les nouvelles règles de réseau ne s'appliquent pas, ce qui peut perturber la connectivité réseau ou empêcher l'application des règles pour cette charge de travail.

Étapes suivantes