Overview

This page provides an overview of project network policies in Google Distributed Cloud (GDC) air-gapped.

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.

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.

Global project network policies

You can create global project network policies. The scope of global project network policies span across a GDC universe. Each GDC universe can consist of multiple GDC zones organized into regions that are interconnected and share a control plane. For example, a universe consisting two regions with three zones each might look like: us-virginia1-a, us-virginia1-b, us-virginia1-c and eu-ams1-a, eu-ams1-b, eu-ams1-c.

The scope of zonal project network policies is limited to the zones specified at the time of creation. Each zone is an independent disaster domain. A zone manages infrastructure, services, APIs, and tooling that use a local control plane.

For more information on global resources in a GDC universe, see Multi-zone overview.

You can create global project network policies using the Networking Kubernetes Resource Model (KRM) API. Use the API version networking.global.gdc.goog to create global resources.

You can create zonal project network policies using the KRM API or the GDC console. Use the API version networking.gdc.goog to create zonal resources.

Workload-level network policies

You can create workload-level network policies to define fine-grained access control for individual VMs and pods within a project. These policies act like firewalls for your workloads, controlling traffic flow based on labels to enhance security and isolate applications. This granularity allows stricter control over which workloads can communicate with each other within and across projects.

Workload-level network policies also provide the capability to enforce PNP along a single zone.

For more information, see Create workload-level network policies.

Prepare predefined roles and access

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.
  • Global PNP Admin: has write permissions on all multi-zone PNP resources in global project namespace. Ask your Organization IAM Admin to grant you the Global PNP Admin (global-project-networkpolicy-admin) role. For more information, see Predefined role descriptions.

What's next