Create explicit deny network policies

This page provides instructions to configure explicit deny project network policies in Google Distributed Cloud (GDC) air-gapped.

Explicit deny rules allow you to restrict connectivity between workloads and services in different projects or CIDR ranges. In project network policies, explicit Deny rules take absolute precedence over Allow rules.

Potential for Traffic Disruption (Default-Deny behavior)

In GDC, as soon as a workload is selected by any project network policy (whether it contains `Allow` or `Deny` rules), the workload enters a default-deny mode for that direction (ingress or egress).

Since ingress does not have default platform base rules, applying a project network policy with only `Deny` rules will cause the workload to enter default-deny mode and block all ingress traffic (the specified traffic is blocked by the `Deny` rules, and the rest is blocked by the default-deny behavior).

If you want to use `Deny` rules to block specific ingress traffic while keeping other traffic open, you must also configure `Allow` rules to explicitly permit the traffic you want to preserve.

Before you begin

To configure explicit deny project network policies, you must have the following:

• The necessary identity and access roles. To manage policies for a specific project, you need the project-networkpolicy-admin role. For multi-zone environments where you need to manage policies that span across all zones, you need the global-project-networkpolicy-admin role. For more information, see Prepare predefined roles and access.
• An existing project. For more information, see Create a project.
• For egress network policies, you must also disable data exfiltration protection for the project.

Create a deny network policy

You can define ingress or egress deny policies to restrict communication.

Create an ingress deny policy

To block incoming traffic from workloads in another project within your organization, you must configure an ingress policy with the Deny action.

The following policy blocks workloads in the PROJECT_1 project from receiving connections from workloads in the PROJECT_2 project.

Apply the policy:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: deny-ingress-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - action: Deny
    from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
EOF

Replace the following:

• GLOBAL_API_SERVER: the global API server's kubeconfig path. For more information, see Global and zonal API servers.
• PROJECT_1: the namespace of the project where you want to apply the policy.
• PROJECT_2: the namespace of the project from which traffic should be denied.

Create an egress deny policy

To block outgoing traffic from workloads in your project to workloads in another project within your organization, you must configure an egress policy with the Deny action.

The following policy blocks workloads in the PROJECT_1 project from initiating connections to workloads in the PROJECT_2 project.

Apply the policy:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: deny-egress-to-PROJECT_2
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - action: Deny
    to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
EOF

Replace the following:

• GLOBAL_API_SERVER: the global API server's kubeconfig path.
• PROJECT_1: the namespace of the project where you want to apply the policy.
• PROJECT_2: the namespace of the project to which traffic should be denied.

Key constraints and safety features

To prevent accidental misconfiguration and protect platform traffic, project network policies enforce the following safety checks for deny rules:

• Egress Safety Rules: For egress policies, the system automatically injects rules to exclude system and non-project namespaces. This ensures egress Deny rules don't accidentally block communication to essential platform infrastructure services (such as the API server or DNS).
• Required Peer Specification: Ingress Deny rules must explicitly specify a source peer in the from field. You cannot select all sources by leaving the source peer empty. Omitting the from block or leaving it empty is disallowed, and the policy will be rejected.
• IPBlock Deny Rules and Infrastructure Traffic: If you use ipBlock in egress Deny rules, safety rules cannot be injected. Once the feature that allows selecting nodes using IP blocks is enabled (see Node selection and scale considerations), there is a risk that broad egress Deny rules might block infrastructure traffic. Carefully configure IP blocks for egress Deny policies.