Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, você encontra instruções para configurar políticas de rede de tráfego entre projetos no dispositivo com isolamento físico do Google Distributed Cloud (GDC).
O tráfego entre projetos se refere à comunicação entre serviços e cargas de trabalho de namespaces de projetos diferentes, mas dentro da mesma organização.
Por padrão, os serviços e as cargas de trabalho em um projeto são isolados de serviços e cargas de trabalho externos. No entanto, serviços e cargas de trabalho de namespaces de projetos diferentes e dentro da mesma organização podem se comunicar entre si aplicando políticas de rede de tráfego entre projetos.
Antes de começar
Para configurar políticas de rede de tráfego entre projetos, você precisa ter o seguinte:
Um projeto atual. Para mais informações, consulte Criar um projeto.
Criar uma política de tráfego entre projetos
É possível definir políticas de tráfego de entrada ou saída entre projetos para gerenciar a comunicação entre eles.
Criar uma regra de firewall de entrada para tráfego entre projetos
Para que as cargas de trabalho ou os serviços do projeto permitam conexões de outras cargas de trabalho em outro projeto, configure uma regra de firewall de entrada para permitir o tráfego de entrada de outras cargas de trabalho do projeto.
Siga as etapas abaixo para criar uma regra de firewall e permitir o tráfego de entrada de cargas de trabalho em outro projeto:
Console
No console do GDC do projeto que você está configurando, acesse Rede>Firewall no menu de navegação para abrir a página Firewall.
Clique em Criar na barra de ações para começar a criar uma regra de firewall.
Na página Detalhes da regra de firewall, preencha as seguintes informações:
No campo Nome, insira um nome válido para a regra de firewall.
Na seção Direção do tráfego, selecione Entrada para permitir o tráfego de entrada de cargas de trabalho em outros projetos.
Na seção Segmentar, selecione uma das seguintes opções:
Todas as cargas de trabalho do usuário:permite conexões com as cargas de trabalho do projeto que você está configurando.
Serviço:indica que essa regra de firewall tem como destino um serviço específico no projeto que você está configurando.
Se o destino for um serviço do projeto, selecione o nome dele no menu suspenso Serviço.
Na seção De, selecione uma das seguintes opções:
Todos os projetos:permite conexões de cargas de trabalho em todos os projetos.
Outro projeto e Todas as cargas de trabalho do usuário:permitem conexões de cargas de trabalho em outro projeto.
Se você quiser transferir cargas de trabalho apenas de outro projeto, selecione um projeto a que você tenha acesso na lista de projetos do menu suspenso ID do projeto.
Se o destino for todas as cargas de trabalho do usuário, selecione uma das seguintes opções na seção Protocolos e portas:
Permitir tudo:permite conexões usando qualquer protocolo ou porta.
Protocolos e portas especificados:permitem conexões usando apenas os protocolos e portas especificados nos campos correspondentes da regra de firewall de entrada.
Na página Detalhes da regra de firewall, clique em Criar.
Agora você permitiu conexões de outras cargas de trabalho do projeto. Depois de criar a regra de firewall, ela fica visível em uma tabela na página Firewall.
API
A política a seguir permite que as cargas de trabalho no projeto PROJECT_1 aceitem conexões de cargas de trabalho no projeto PROJECT_2, bem como o tráfego de retorno para os mesmos fluxos. Aplique a política:
Substitua API_SERVER pelo caminho kubeconfig do servidor da API.
Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
O comando anterior permite que PROJECT_2 acesse PROJECT_1, mas não permite conexões iniciadas de PROJECT_1 para PROJECT_2. Para o último, é preciso ter uma política recíproca no projeto PROJECT_2. Aplique a política de reciprocidade:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
