Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina fornisce istruzioni per configurare i criteri di rete per il traffico tra progetti nell'appliance con air gap di Google Distributed Cloud (GDC).
Il traffico tra progetti si riferisce alla comunicazione tra servizi e carichi di lavoro di spazi dei nomi di progetti diversi, ma all'interno della stessa organizzazione.
Per impostazione predefinita, i servizi e i workload di un progetto sono isolati da servizi e workload esterni. Tuttavia, i servizi e i carichi di lavoro di spazi dei nomi di progetti diversi e all'interno della stessa organizzazione possono comunicare tra loro applicando criteri di rete per il traffico tra progetti.
Prima di iniziare
Per configurare i criteri di rete per il traffico intra-progetto, devi disporre di quanto segue:
Crea una policy di gestione del traffico tra progetti
Puoi definire criteri di traffico tra progetti in entrata o in uscita per gestire la comunicazione tra i progetti.
Crea una regola firewall in entrata per il traffico tra progetti
Affinché i servizi o i carichi di lavoro del progetto consentano le connessioni da altri carichi di lavoro in un altro progetto, devi configurare una regola firewall in entrata per consentire il traffico in entrata di altri carichi di lavoro del progetto.
Segui questi passaggi per creare una nuova regola firewall e consentire il traffico in entrata dai carichi di lavoro in un altro progetto:
Console
Nella console GDC del progetto che stai configurando, vai a Networking>Firewall nel menu di navigazione per aprire la pagina Firewall.
Fai clic su Crea nella barra delle azioni per iniziare a creare una nuova regola firewall.
Nella pagina Dettagli regola firewall, inserisci le seguenti informazioni:
Nel campo Nome, inserisci un nome valido per la regola firewall.
Nella sezione Direzione del traffico, seleziona In entrata per consentire il traffico in entrata dai carichi di lavoro in altri progetti.
Nella sezione Target, seleziona una delle seguenti opzioni:
Tutti i workload utente: consentono le connessioni ai workload del progetto che stai configurando.
Servizio:indica che questa regola firewall ha come target un servizio specifico all'interno del progetto che stai configurando.
Se la destinazione è un servizio di progetto, seleziona il nome del servizio dall'elenco dei servizi disponibili nel menu a discesa Servizio.
Nella sezione Da, seleziona una delle seguenti due opzioni:
Tutti i progetti:consente le connessioni dai carichi di lavoro in tutti i progetti.
Un altro progetto e Tutti i workload utente consentono le connessioni dai workload in un altro progetto.
Se vuoi trasferire i carichi di lavoro solo da un altro progetto, seleziona un progetto a cui puoi accedere dall'elenco dei progetti nel menu a discesa ID progetto.
Se il target sono tutti i carichi di lavoro utente, seleziona una delle seguenti opzioni nella sezione Protocolli e porte:
Consenti tutto:consente le connessioni utilizzando qualsiasi protocollo o porta.
Protocolli e porte specificati:consentono le connessioni utilizzando solo i protocolli e le porte specificati nei campi corrispondenti per la regola firewall in entrata.
Nella pagina Dettagli regola firewall, fai clic su Crea.
Ora hai consentito le connessioni da altri workload del progetto. Dopo aver creato la regola firewall, questa è visibile in una tabella nella pagina Firewall.
API
La seguente policy consente ai carichi di lavoro nel progetto PROJECT_1 di consentire le connessioni dai carichi di lavoro nel progetto PROJECT_2, nonché il traffico di ritorno per gli stessi flussi. Applica le norme:
Sostituisci API_SERVER con il percorso kubeconfig del server API.
Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per i dettagli.
Il comando precedente consente a PROJECT_2 di andare a
PROJECT_1, ma non consente le connessioni avviate da
PROJECT_1 a PROJECT_2. Per
quest'ultimo, è necessaria una policy reciproca nel progetto
PROJECT_2. Applica
la norma di reciprocità:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
