Configure project network policies

This document describes the administrative operations available to configure project network policies.

Before you begin

To configure project network policies, you must have the necessary identity and access roles:

Project NetworkPolicy Admin: manages project network policies in the project namespace. Ask your Organization IAM Admin to grant you the Project NetworkPolicy Admin (project-networkpolicy-admin) cluster role.

Security and connectivity

By default, services and workloads in a project are isolated within that project. They cannot communicate with external services and workloads without configuring a network policy.

To set a network policy for your project namespace in GDC, use the ProjectNetworkPolicy resource. This resource lets you define policies, which allow communication within projects, between projects, to external IP addresses, and from external IP addresses. Also, you can transfer workloads out from a project only if you disable data exfiltration protection for the project.

GDC project network policies are additive. The resulting enforcement for a workload is an any match for the traffic flow against the union of all policies applied to that workload. When multiple policies are present, the rules for each policy are additively combined, allowing traffic if it matches at least one of the rules.

Furthermore, after you apply a single policy, all traffic you don't specify is denied. Therefore, when you apply one or more policies that select a workload as the subject, only the traffic that a policy specifies is allowed.

When you use a well-known IP address you allocate for the project, it performs a source network address translation (NAT) on the outbound traffic from the organization.

Configure a project network policy

This section describes how to set a network policy for workloads at the project namespace level, using the ProjectNetworkPolicy resource, which is a multi-cluster network policy for Google Distributed Cloud (GDC) air-gapped. This resource lets you define policies that allow communication within projects, between projects, and to external IP addresses.

Project network policies define either ingress or egress rules. Unlike Kubernetes network policies, you can only specify one policy type for a policy.

For traffic within a project, GDC applies a predefined project network policy, the intra-project policy, to each project by default.

Services 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.

Similarly, 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.

Ingress and egress firewall rules are the main components of project network policies and determine which types of traffic are allowed in and out of your network. To set firewall rules for your project namespace in GDC, use the GDC console.

Intra-project traffic

By default, workloads in a project namespace have the ability to communicate with each other without exposing anything to external resources.

Ingress intra-project traffic network policy

When you create a project, you implicitly create a default base ProjectNetworkPolicy that allows intra-project communication. This policy allows inbound traffic from other services in the same project.

You can remove the default policy, but be aware that this removal results in denying intra-project communication for all services and workloads within the project.

Egress intra-project traffic network policy

By default, there is no egress policy, so outbound traffic is allowed for all intra-project traffic. However, when you set a single egress policy, only the traffic that the policy specifies is allowed.

When you disable data exfiltration prevention and apply a ProjectNetworkPolicy egress policy to the project, such as preventing access to an external resource, use the following required policy to allow intra-project outbound traffic:

kubectl --kubeconfig ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-intra-project-outbound-traffic
spec:
  policyType: Egress
  egress:
  - to:
    - projects:
        matchNames:
        - PROJECT
EOF

Replace PROJECT with the name of the project where you want to allow intra-project outbound traffic.

Cross-project traffic

Cross-project traffic refers to the communication between services and workloads from different project namespaces but within the same organization.

Create an ingress firewall rule for cross-project traffic

For 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.

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

GDC 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 projects.
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 one of the following two options:
  - All projects: allow connections from workloads in all the projects of the same organization.
  - Another project and All user workloads: allow connections from workloads in another project of the same organization.
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.
7. 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 other project workloads within the same organization. After creating the firewall rule, the rule is visible in a table on the Firewall page.

API

For project resources to allow connections from other resources in another project, you must configure an ingress policy to allow inbound traffic from the other project resources.

The following policy enables workloads in the PROJECT_1 project to permit connections from workloads in the PROJECT_2 project, as well as the return traffic for the same flows. Apply the policy:

kubectl --kubeconfig ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-inbound-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_2
EOF

The preceding command allows PROJECT_2 to go to PROJECT_1, but doesn't allow connections initiated from PROJECT_1 to PROJECT_2. For the latter, you require a reciprocal policy in the PROJECT_2 project. Apply the reciprocal policy:

kubectl --kubeconfig ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-inbound-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Connections are now permitted to and from PROJECT_1 and PROJECT_2.

Create an egress firewall rule for cross-project traffic

When 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.

For example, if you create a policy allowing traffic from PROJECT_1 to PROJECT_2 and data exfiltration protection is disabled, you must create an ingress policy in PROJECT_2 and an egress policy on PROJECT_1. However, the reply packets are excluded from the policy enforcement, so you don't require any additional policies.

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

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 one of the following two options:
  - All projects: allow connections to workloads in all the projects of the same organization.
  - Another project and All user workloads: allow connections to workloads in another project of the same organization.
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.
7. 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 other project workloads within the same organization. After creating the firewall rule, the rule is visible in a table on the Firewall page.

Cross-organization traffic

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

Create an 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.

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

GDC 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 ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: networking.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

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 an 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.

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:

GDC 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.

These directions show you how to enable your customized egress policy:

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

Use the following example:

kubectl --kubeconfig ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-outbound-traffic-to-NAME
spec:
  policyType: Egress
  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 ORG_ADMIN_CLUSTER_KUBECONFIG \
    get projectnetworkpolicy allow-outbound-traffic-to-NAME \
    -n PROJECT -o yaml
```
Replace the following:
- ORG_ADMIN_CLUSTER_KUBECONFIG: the kubeconfig file for the org admin cluster.
- PROJECT: the name of the GDC project.
- NAME: a name associated with the destination.

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

Policies for managed services

By default, a managed service only allows connections from the project that created the service. An operator can expose the managed service to projects other than the project that created the service by using a project network policy.

For example, the following ProjectNetworkPolicy exposes the Database Service (DBS) as a managed service:

kubectl --kubeconfig ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-inbound-traffic-from-project-2-to-dbs-service
spec:
  subject:
    subjectType: ManagedService
    managedServices:
      matchTypes:
      - 'dbs'
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_2
EOF

Workloads from the PROJECT_2 project can connect to workloads in the DBS managed service.

View the firewall rules of your organization

To view all the firewall rules associated with your organization from the GDC console, follow these steps:

Within the GDC console of your organization, go to Networking > Firewall in the navigation menu.

The Firewall page displays the table of ingress and egress firewall rules for the project network policies your organization has. These firewall rules establish communication within and between projects, as well as between organizations and managed services. The page classifies the existing rules as user-created and system-defined rules.
Optional: Use filtering to narrow the results in the table based on property names or values.
To view more details about a firewall rule, click its name.

Edit a firewall rule

To edit an existing firewall rule, follow these steps:

Within the GDC console of your organization, go to Networking > Firewall in the navigation menu.

The Firewall page displays the table of ingress and egress firewall rules for the project network policies your organization has. These firewall rules are classified as user-created or system-defined rules.

Note: System-defined rules cannot be edited using the UI.
Click the name of the firewall policy you want to edit.
Click Edit.
Make your changes. You can update all properties of the firewall rule except for the Name.

Delete a firewall rule

To delete an existing firewall rule, follow these steps:

Within the GDC console of your organization, go to Networking > Firewall in the navigation menu.

The Firewall page displays the table of ingress and egress firewall rules for the project network policies your organization has. These firewall rules are classified as user-created or system-defined rules.

Note: System-defined rules cannot be deleted using the UI.
Click the name of the firewall policy you want to delete.
Click Delete.
Click Delete.