Create intra-project network policies

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

Project network policies define either ingress or egress rules. You can define policies that allow communication within projects, between projects, and to external IP addresses.

By default, these policies apply globally across all zones. For more information on global resources in a GDC universe, see Multi-zone overview.

If intra-project traffic enforcement is needed within a single zone, see Create a single zone workload-level intra-project policy.

Before you begin

To configure intra-project traffic 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.

Create an intra-project policy

For traffic within a project, GDC applies a predefined project network policy, the intra-project policy, to each project by default. By default, workloads in a project namespace have the ability to communicate with each other without exposing anything to external resources.

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.

Create an ingress intra-project policy

When you create a project, you implicitly create a default base ProjectNetworkPolicy resource that allows intra-project communication. This policy allows inbound traffic from other workloads 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. To remove the policy, use the kubectl delete command:

kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT

You can add the default policy back by applying the following manifest:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: base-policy-allow-intra-project-traffic
spec:
  policyType: Ingress
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
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 your project.

Create an egress intra-project policy

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 GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-intra-project-outbound-traffic
spec:
  policyType: Egress
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
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 your project.

Create a workload-level intra-project policy

Workload-level network policies offer granular control over communication between individual workloads within a project. This granularity allows stricter control of network access, improving security and resource use.

Create an ingress workload-level intra-project policy

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

To create an ingress workload-level intra-project policy, the default base policy must first be deleted. Otherwise, unexpected behavior may occur.

  1. To delete the default base policy, run the following command:

    kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
    
  2. To create an ingress workload-level intra-project policy, create and apply the following custom resource:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT
      name: allow-intra-project-inbound-traffic-from-target-to-subject
    spec:
      policyType: Ingress
      subject:
        subjectType: UserWorkload
        workloadSelector:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
      ingress:
      - from:
        - projectSelector:
            projects:
              matchNames:
              - PROJECT
            workloads:
              matchLabels:
                TARGET_LABEL_KEY: TARGET_LABEL_VALUE
    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 your project.
    • SUBJECT_LABEL_KEY: the key of the label used to select the source workloads. For example, app, tier, or role.
    • SUBJECT_LABEL_VALUE: the value associated with the SUBJECT_LABEL_KEY. It specifies which workloads are the source of the allowed traffic. For example, if SUBJECT_LABEL_KEY is app, and SUBJECT_LABEL_VALUE is backend, then workloads with the label app: backend is the traffic source.
    • TARGET_LABEL_KEY: the key of the label used to select the destination workloads.
    • TARGET_LABEL_VALUE: the value associated with the TARGET_LABEL_KEY. It specifies which workloads are the destination of the allowed traffic.

Create an egress workload-level intra-project policy

  • To create an egress workload-level intra-project policy, create and apply the following custom resource:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT
      name: allow-intra-project-outbound-traffic-to-subject-from-target
    spec:
      policyType: Egress
      subject:
        subjectType: UserWorkload
        workloadSelector:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
      egress:
      - to:
        - projectSelector:
            projects:
              matchNames:
              - PROJECT
            workloads:
              matchLabels:
                TARGET_LABEL_KEY: TARGET_LABEL_VALUE
    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 your project.
    • SUBJECT_LABEL_KEY: the key of the label used to select the source workloads. For example, app, tier, or role.
    • SUBJECT_LABEL_VALUE: the value associated with the SUBJECT_LABEL_KEY. It specifies which workloads are the source of the allowed traffic. For example, if SUBJECT_LABEL_KEY is app, and SUBJECT_LABEL_VALUE is backend, then workloads with the label app: backend is the traffic source.
    • TARGET_LABEL_KEY: the key of the label used to select the destination workloads.
    • TARGET_LABEL_VALUE: the value associated with the TARGET_LABEL_KEY. It specifies which workloads are the destination of the allowed traffic.

Create a single zone workload-level intra-project policy

Workload-level network policies can enforce PNP along a single zone. Specific labels can be added to workloads within a single zone, allowing you to control communication between individual workloads within a project or in different projects for that zone.

Create a single zone ingress workload-level intra-project policy

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

To create a single zone ingress workload-level intra-project policy, the default base policy must first be deleted. Otherwise, unexpected behavior may occur.

  1. To delete the default base policy, run the following command:

    kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
    
  2. To create a single zone ingress workload-level intra-project traffic network policy, create and apply the following custom resource:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT
      name: allow-single-zone-intra-project-inbound-traffic-from-target-to-subject
    spec:
      policyType: Ingress
      subject:
        subjectType: UserWorkload
        workloadSelector:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
      ingress:
      - from:
        - projectSelector:
            projects:
              matchNames:
              - PROJECT
            workloads:
              matchLabels:
                TARGET_LABEL_KEY: TARGET_LABEL_VALUE
                ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
    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 your project.
    • SUBJECT_LABEL_KEY: the key of the label used to select the source workloads. For example, app, tier, or role.
    • SUBJECT_LABEL_VALUE: the value associated with the SUBJECT_LABEL_KEY. It specifies which workloads are the source of the allowed traffic. For example, if SUBJECT_LABEL_KEY is app, and SUBJECT_LABEL_VALUE is backend, then workloads with the label app: backend is the traffic source.
    • TARGET_LABEL_KEY: the key of the label used to select the destination workloads.
    • TARGET_LABEL_VALUE: the value associated with the TARGET_LABEL_KEY. It specifies which workloads are the destination of the allowed traffic.
    • ZONE_SUBJECT_LABEL_KEY: the key of the label used to select the source zone. For example, zone, or region.
    • ZONE_SUBJECT_LABEL_VALUE: the value associated with the ZONE_SUBJECT_LABEL_KEY. It specifies which zone is the source of the allowed traffic. For example, if ZONE_SUBJECT_LABEL_KEY is zone, and ZONE_SUBJECT_LABEL_VALUE is us-central1-a, then workloads with the label zone: us-central1-a is the traffic source.
    • ZONE_TARGET_LABEL_KEY: the key of the label used to select the destination zone.
    • ZONE_TARGET_LABEL_VALUE: the value associated with the ZONE_TARGET_LABEL_KEY. It specifies which zone is the destination of the allowed traffic.

Create a single zone egress workload-level intra-project policy

  • To create a single zone egress workload-level intra-project policy, create and apply the following custom resource:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT
      name: allow-single-zone-intra-project-outbound-traffic-to-subject-from-target
    spec:
      policyType: Egress
      subject:
        subjectType: UserWorkload
        workloadSelector:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
      egress:
      - to:
        - projectSelector:
            projects:
              matchNames:
              - PROJECT
            workloads:
              matchLabels:
                TARGET_LABEL_KEY: TARGET_LABEL_VALUE
                ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
    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 your project.
    • SUBJECT_LABEL_KEY: the key of the label used to select the source workloads. For example, app, tier, or role.
    • SUBJECT_LABEL_VALUE: the value associated with the SUBJECT_LABEL_KEY. It specifies which workloads are the source of the allowed traffic. For example, if SUBJECT_LABEL_KEY is app, and SUBJECT_LABEL_VALUE is backend, then workloads with the label app: backend is the traffic source.
    • TARGET_LABEL_KEY: the key of the label used to select the destination workloads.
    • TARGET_LABEL_VALUE: the value associated with the TARGET_LABEL_KEY. It specifies which workloads are the destination of the allowed traffic.
    • ZONE_SUBJECT_LABEL_KEY: the key of the label used to select the source zone. For example, zone, or region.
    • ZONE_SUBJECT_LABEL_VALUE: the value associated with the ZONE_SUBJECT_LABEL_KEY. It specifies which zone is the source of the allowed traffic. For example, if ZONE_SUBJECT_LABEL_KEY is zone, and ZONE_SUBJECT_LABEL_VALUE is us-central1-a, then workloads with the label zone: us-central1-a is the traffic source.
    • ZONE_TARGET_LABEL_KEY: the key of the label used to select the destination zone.
    • ZONE_TARGET_LABEL_VALUE: the value associated with the ZONE_TARGET_LABEL_KEY. It specifies which zone is the destination of the allowed traffic.