Créer des règles de réseau de trafic inter-projets
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page explique comment configurer des règles de réseau de trafic inter-projets dans l'appliance Google Distributed Cloud (GDC) sous air gap.
Le trafic inter-projets fait référence à 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.
Avant de commencer
Pour configurer des règles de réseau de trafic intra-projet, vous devez disposer des éléments suivants :
Un projet existant. Pour en savoir plus, consultez Créer un projet.
Créer une règle de trafic 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 de pare-feu d'entrée pour le trafic entre projets
Pour que les charges de travail ou les services d'un projet autorisent les connexions provenant d'autres charges de travail dans un autre projet, vous devez configurer une règle de pare-feu d'entrée afin d'autoriser le trafic entrant des autres charges de travail du projet.
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
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 :
Dans le champ Nom, saisissez un nom valide pour votre règle de pare-feu.
Dans la section Direction du trafic, sélectionnez Entrée pour autoriser le trafic entrant des charges de travail d'autres projets.
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.
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.
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.
Autre projet et Toutes les charges de travail utilisateur : autorisent les connexions depuis les charges de travail d'un autre projet.
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.
Si votre cible concerne toutes les charges de travail utilisateur, sélectionnez l'une des options suivantes dans la section Protocoles et ports :
Tout autoriser : 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 maintenant autorisé les connexions à partir des charges de travail d'autres projets. 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 :
Remplacez API_SERVER par le chemin d'accès kubeconfig du serveur API.
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 la règle de réciprocité :
Les connexions vers et depuis PROJECT_1 et PROJECT_2 sont désormais autorisées.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["# Create cross-project traffic network policies\n\nThis page provides instructions to configure cross-project traffic network policies in Google Distributed Cloud (GDC) air-gapped appliance.\n\nCross-project traffic refers to the communication between services and workloads from different project namespaces but within the same organization.\n\nServices and workloads in a project are isolated from external services and workloads by default. However, services and workloads from different project namespaces and within the same organization can communicate with each other by applying cross-project traffic network policies.\n\nBefore you begin\n----------------\n\nTo configure intra-project traffic network policies, you must have the following:\n\n- The necessary identity and access roles. For more information, see [Prepare predefined roles and access](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/pnp/pnp-overview#prepare-predefined-roles-and-access).\n- An existing project. For more information, see [Create a project](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/create-a-project).\n\nCreate a cross-project traffic policy\n-------------------------------------\n\nYou can define ingress or egress cross-project traffic policies to manage the communication between projects.\n\n### Create an ingress firewall rule for cross-project traffic\n\nFor project workloads or services to allow connections from other workloads in another project, you must configure an ingress firewall rule to allow the inbound traffic of other project workloads.\n\nWork through the following steps to create a new firewall rule and allow inbound traffic from workloads in another project: \n\n### Console\n\n1. Within the GDC console of the project you are configuring, go to **Networking** \\\u003e **Firewall** in the navigation menu to open the **Firewall** page.\n2. Click **Create** in the action bar to begin creating a new firewall rule.\n3. On the **Firewall rule details** page, fill out the following information:\n\n 1. In the **Name** field, enter a valid name for your firewall rule.\n 2. In the **Direction of traffic** section, select **Ingress** to allow inbound traffic from workloads in other projects.\n 3. In the **Target** section, select one of the following options:\n - **All user workloads:** allow connections to the workloads of the project you are configuring.\n - **Service:** indicate that this firewall rule targets a specific service within the project you are configuring.\n 4. If your target is a project service, select the name of the service from the list of available services on the **Service** drop-down menu.\n 5. In the **From** section, select one of the following two options:\n - **All projects:** allow connections from workloads in all the projects.\n - **Another project** and **All user workloads:** allow connections from workloads in another project.\n 6. If you want to transfer workloads only from another project, select a project that you can access from the list of projects on the **Project ID** drop-down menu.\n 7. If your target is all user workloads, select one of the following options in the **Protocols and ports** section:\n - **Allow all:** allow connections using any protocol or port.\n - **Specified protocols and ports:** allow connections using only the protocols and ports that you specify in the corresponding fields for the ingress firewall rule.\n4. On the **Firewall rule details** page, click **Create**.\n\nYou've now permitted connections from other project workloads. After creating the firewall rule, the rule is visible in a table on the **Firewall** page.\n\n### API\n\nThe following policy enables workloads in the \u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e\nproject to permit connections from workloads in the\n\u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e project, as well as the return traffic for\nthe same flows. Apply the policy: \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eAPI_SERVER\u003c/var\u003e apply -f - \u003c\u003cEOF\n apiVersion: networking.global.gdc.goog/v1\n kind: ProjectNetworkPolicy\n metadata:\n namespace: \u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e\n name: allow-inbound-traffic-from-\u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e\n spec:\n policyType: Ingress\n subject:\n subjectType: UserWorkload\n ingress:\n - from:\n - projectSelector:\n projects:\n matchNames:\n - \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e\n EOF\n\nReplace \u003cvar translate=\"no\"\u003eAPI_SERVER\u003c/var\u003e with the API\nserver's kubeconfig path.\nIf you have not yet generated a kubeconfig file for the API server,\nsee [Sign in](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/iam/sign-in#cli) for\ndetails.\n\nThe preceding command allows \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e to go to\n\u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e, but doesn't allow connections initiated from\n\u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e to \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e. For\nthe latter, you require a reciprocal policy in the\n\u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e project. Apply\nthe reciprocal policy: \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eAPI_SERVER\u003c/var\u003e apply -f - \u003c\u003cEOF\n apiVersion: networking.global.gdc.goog/v1\n kind: ProjectNetworkPolicy\n metadata:\n namespace: \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e\n name: allow-inbound-traffic-from-\u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e\n spec:\n policyType: Ingress\n subject:\n subjectType: UserWorkload\n ingress:\n - from:\n - projectSelector:\n projects:\n matchNames:\n - \u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e\n EOF\n\nConnections are now permitted to and from\n\u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e and \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e."]]
