한 프로젝트의 워크로드가 다른 프로젝트의 워크로드로부터 연결을 허용하도록 인그레스 교차 프로젝트 트래픽 정책을 부여하면 이 작업은 동일한 흐름의 반환 트래픽도 부여합니다. 따라서 원래 프로젝트에는 이그레스 교차 프로젝트 트래픽 네트워크 정책이 필요하지 않습니다.
이 전역 이그레스 정책은 GDC 유니버스의 모든 영역에만 적용됩니다.
예를 들어 PROJECT_1에서 PROJECT_2로의 트래픽을 허용하는 정책을 만들고 데이터 무단 반출 보호가 사용 중지된 경우 PROJECT_2에 인그레스 정책을 만들고 PROJECT_1에 이그레스 정책을 만들어야 합니다. 하지만 응답 패킷은 정책 시행에서 제외되므로 추가 정책이 필요하지 않습니다.
다음 단계에 따라 새 방화벽 규칙을 만들고 프로젝트의 워크로드에서 아웃바운드 트래픽을 허용합니다.
구성 중인 프로젝트의 GDC 콘솔에서 탐색 메뉴의 네트워킹>방화벽으로 이동하여 방화벽 페이지를 엽니다.
작업 표시줄에서 만들기를 클릭하여 새 방화벽 규칙을 만듭니다.
방화벽 규칙 세부정보 페이지에서 다음 정보를 입력합니다.
이름 필드에 방화벽 규칙의 유효한 이름을 입력합니다.
트래픽 방향 섹션에서 이그레스를 선택하여 이 방화벽 규칙이 아웃바운드 트래픽을 제어하고 있음을 나타냅니다.
타겟 섹션에서 다음 옵션 중 하나를 선택합니다.
모든 사용자 워크로드: 구성 중인 프로젝트의 워크로드에서 연결을 허용합니다.
서비스: 이 방화벽 규칙이 구성 중인 프로젝트 내의 특정 서비스를 타겟팅함을 나타냅니다.
타겟이 프로젝트 서비스인 경우 서비스 드롭다운 메뉴의 사용 가능한 서비스 목록에서 서비스 이름을 선택합니다.
받는 사람 섹션에서 다음 두 가지 옵션 중 하나를 선택합니다.
모든 프로젝트: 동일한 조직의 모든 프로젝트에 있는 워크로드에 대한 연결을 허용합니다.
다른 프로젝트 및 모든 사용자 워크로드: 동일한 조직의 다른 프로젝트에 있는 워크로드에 연결을 허용합니다.
워크로드를 다른 프로젝트로만 전송하려면 프로젝트 ID 드롭다운 메뉴의 프로젝트 목록에서 액세스할 수 있는 프로젝트를 선택합니다.
타겟이 모든 사용자 워크로드인 경우 프로토콜 및 포트 섹션에서 다음 옵션 중 하나를 선택합니다.
모두 허용: 모든 프로토콜 또는 포트를 사용하여 연결을 허용합니다.
지정된 프로토콜 및 포트: 이그레스 방화벽 규칙의 해당 필드에 지정된 프로토콜 및 포트만 사용하여 연결을 허용합니다.
방화벽 규칙 세부정보 페이지에서 만들기를 클릭합니다.
이제 동일한 조직 내의 다른 프로젝트 워크로드에 대한 연결이 허용되었습니다. 방화벽 규칙을 만들면 방화벽 페이지의 표에 규칙이 표시됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThis page outlines how to configure cross-project traffic network policies in Google Distributed Cloud (GDC) air-gapped, enabling communication between services and workloads across different project namespaces within the same organization.\u003c/p\u003e\n"],["\u003cp\u003eBy default, services and workloads in a project are isolated, but cross-project communication can be established by defining ingress or egress firewall rules.\u003c/p\u003e\n"],["\u003cp\u003eGlobal cross-project network policies apply to all zones within your GDC universe, and both console and API methods can be used to create these policies.\u003c/p\u003e\n"],["\u003cp\u003eIngress firewall rules allow inbound traffic from workloads in other projects, while egress rules control outbound traffic to other project workloads.\u003c/p\u003e\n"],["\u003cp\u003eGranting an ingress policy also grants return traffic, so you do not require a secondary egress policy.\u003c/p\u003e\n"]]],[],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.\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\nIf cross-project traffic enforcement is needed within a single zone, see [Create workload-level network policies](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/pnp/workload-level-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/gdch/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/gdch/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\nYou can create global cross-project network policies that apply to all of the zones in your GDC universe. For more information, see [What is a universe?](/distributed-cloud/hosted/docs/latest/gdch/resources/multi-zone/mz-overview#deployment-hierarchy-overview)\n\n### Create a global ingress firewall rule for cross-project traffic\n\nFor project workloads or services to allow connections from other workloads in another project within your organization, you must configure an ingress firewall rule to allow the inbound traffic of other project workloads.\n\nThis global ingress policy applies to all zones in your organization.\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 of the same organization.\n - **Another project** and **All user workloads:** allow connections from workloads in another project of the same organization.\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 within the same organization. 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\"\u003eGLOBAL_API_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\"\u003eGLOBAL_API_SERVER\u003c/var\u003e with the global API\nserver's kubeconfig path. For more information, see [Global and zonal API servers](/distributed-cloud/hosted/docs/latest/gdch/resources/multi-zone/api-servers).\nIf you have not yet generated a kubeconfig file for the API server,\nsee [Sign in](/distributed-cloud/hosted/docs/latest/gdch/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\"\u003eGLOBAL_API_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.\n\n### Create a global egress firewall rule for cross-project traffic\n\nWhen you grant an ingress cross-project traffic policy to let workloads in one project to allow connections from workloads in another project, this action also grants the return traffic for the same flows. Therefore, you don't need an egress cross-project traffic network policy in the original project.\n\nThis global egress policy only applies to all of the zones in your GDC universe.\n\nFor example, if you create a policy allowing traffic from \u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e to \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e and data exfiltration protection is disabled, you must create an ingress policy in \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e and an egress policy on \u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e. However, the reply packets are excluded from the policy enforcement, so you don't require any additional policies.\n\nWork through the following steps to create a new firewall rule and allow outbound traffic from workloads in a project:\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 **Egress** to indicate that this firewall rule is controlling outbound traffic.\n 3. In the **Target** section, select one of the following options:\n - **All user workloads:** allow connections from 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 **To** section, select one of the following two options:\n - **All projects:** allow connections to workloads in all the projects of the same organization.\n - **Another project** and **All user workloads:** allow connections to workloads in another project of the same organization.\n 6. If you want to transfer workloads only to 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 egress firewall rule.\n4. On the **Firewall rule details** page, click **Create**.\n\nYou've now permitted connections to other project workloads within the same organization. After creating the firewall rule, the rule is visible in a table on the **Firewall** page."]]
