Create cross-organization traffic network policies

This page provides instructions to configure cross-organization traffic network policies in Google Distributed Cloud (GDC) air-gapped.

Cross-organization traffic refers to the communication between services and workloads from different organizations.

Before you begin

To configure cross-organization traffic network policies, you must have the following:

The necessary identity and access roles. For more information, see Prepare predefined roles and access.
An existing project. For more information, see Create a project.
Disable data exfiltration protection.

Create a cross-organization traffic policy

You can define ingress or egress cross-organization traffic policies to manage the communication between services and workloads from different organizations.

Cross-organization traffic refers to the communication between services and workloads from different organizations.

You can create global cross-organization traffic project network policies that apply to traffic across all zones in your organization. For more information on global resources in a GDC universe, see Multi-zone overview.

Connecting services and workloads to a destination outside of your project in a different organization requires explicit approval. You must disable data exfiltration protection to allow cross-organization traffic.

Create a global ingress firewall rule for cross-organization traffic

When exposing workloads in your project using an external load balancer, you must also create a ProjectNetworkPolicy ingress policy to allow external client IP addresses to access the workloads.

This global ingress policy applies to all zones in your organization.

Work through the following steps to create a new firewall rule and allow inbound traffic from workloads in a project of a different organization:

Console

Within the GDC console of the project you are configuring, go to Networking > Firewall in the navigation menu to open the Firewall page.
Click Create in the action bar to begin creating a new firewall rule.
On the Firewall rule details page, fill out the following information:
1. In the Name field, enter a valid name for your firewall rule.
2. In the Direction of traffic section, select Ingress to allow inbound traffic from workloads in other organizations.
3. In the Target section, select one of the following options:
  - All user workloads: allow connections to the workloads of the project you are configuring.
  - Service: indicate that this firewall rule targets a specific service within the project you are configuring.
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.
5. In the From section, select Outside the organization and enter the CIDR block of another organization in the CIDR field to allow connections from that organization's network.
6. If your target is all user workloads, select one of the following options in the Protocols and ports section:
  - Allow all: allow connections using any protocol or port.
  - Specified protocols and ports: allow connections using only the protocols and ports that you specify in the corresponding fields for the ingress firewall rule.
On the Firewall rule details page, click Create.

You've now permitted connections from project workloads of a different organization. After creating the firewall rule, the rule is visible in a table on the Firewall page.

API

Configure and apply your own customized ProjectNetworkPolicy ingress policy:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
EOF

Replace the following:

GLOBAL_API_SERVER: the global API server's kubeconfig path. For more information, see Global and zonal API servers. If you have not yet generated a kubeconfig file for the API server, see Sign in for details.
PROJECT: the name of the GDC project.
CIDR: the CIDR block of another organization.

This policy is required as the external load balancer uses Direct Server Return (DSR), which preserves the source external IP address and bypasses the load balancer on the return path.

Create a global egress firewall rule for cross-organization traffic

To transfer data to services outside of the organization, you must first disable data exfiltration protection. Then, you must configure an egress firewall rule to allow outbound traffic from your project workloads or services.

This section describes the process to enable outbound traffic at the project level. For information about managing egress connectivity at the workload level, see Manage outbound traffic from workloads.

This global egress firewall rules applies to all zones in your organization.

Work through the following steps to create a new firewall rule and allow outbound traffic from project workloads or services to workloads in another organization:

Console

Within the GDC console of the project you are configuring, go to Networking > Firewall in the navigation menu to open the Firewall page.
Click Create in the action bar to begin creating a new firewall rule.
On the Firewall rule details page, fill out the following information:
1. In the Name field, enter a valid name for your firewall rule.
2. In the Direction of traffic section, select Egress to indicate that this firewall rule is controlling outbound traffic.
3. In the Target section, select one of the following options:
  - All user workloads: allow connections from the workloads of the project you are configuring.
  - Service: indicate that this firewall rule targets a specific service within the project you are configuring.
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.
5. In the To section, select Outside the organization and enter the CIDR block of another organization in the CIDR field to allow connections to that organization's network.
6. If your target is all user workloads, select one of the following options in the Protocols and ports section:
  - Allow all: allow connections using any protocol or port.
  - Specified protocols and ports: allow connections using only the protocols and ports that you specify in the corresponding fields for the egress firewall rule.
On the Firewall rule details page, click Create.

You've now permitted connections to another organization. After creating the firewall rule, the rule is visible in a table on the Firewall page.

API

To enable outbound traffic to services outside of the organization, customize your ProjectNetworkPolicy resource. However, because data exfiltration prevention is enabled by default, your customized ProjectNetworkPolicy egress policy shows a validation error in the status field, and the dataplane ignores it. This behavior happens by design.

You can transfer workloads from a given project when you allow data exfiltration for that project. The outbound traffic that you allow is a source network address translation (NAT) using a well-known IP address allocated for the project.

To enable your customized egress policy, follow these steps:

Configure and apply your own customized ProjectNetworkPolicy egress policy on all user workloads in a project.

Use the following example:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-outbound-traffic-to-external
spec:
  subject:
    subjectType: UserWorkload
  egress:
  - to:
    - ipBlock:
        cidr: CIDR
EOF

The policy allows outbound traffic to all hosts in the CIDR block, which reside outside the organization. Your first attempt must cause an intended and necessary status error.

Confirm that you see a validation error in your status.

Important: Only the outbound traffic to destinations outside your project's organization that you explicitly allow in your ProjectNetworkPolicy egress policy configuration is granted. Any other outbound traffic is denied. Therefore, only apply a customized ProjectNetworkPolicy egress policy when requirements mandate such a policy.
Ask the Organization IAM Admin to disable data exfiltration prevention. This action enables your configuration, while preventing all other outbound traffic.

Important: Disabling data exfiltration prevention without defining one or more valid ProjectNetworkPolicy resources permits all outbound traffic to destinations outside your project's organization. Never disable this setting without configuring your customized ProjectNetworkPolicy egress policy.
Check the ProjectNetworkPolicy that you created and verify that the error in the validation status field is gone, and the status Ready is True, indicating that your policy is in effect:
```
kubectl --kubeconfig GLOBAL_API_SERVER \
    get projectnetworkpolicy allow-outbound-traffic-to-external \
    -n PROJECT -o yaml
```
Replace the following:
- GLOBAL_API_SERVER: The global API server's kubeconfig path. For more information, see Global and zonal API servers. If you have not yet generated a kubeconfig file for the API server, see Sign in for details.
- PROJECT: the name of the GDC project.

After you have applied this policy, and provided that you have not defined other egress policies, all other outbound traffic is denied for PROJECT.