4.3.2 Define default deny NetworkPolicies for each workload namespace

Information

Use NetworkPolicy objects to define default deny traffic controls for each GKE workload namespace, then add explicit allow rules for approved pod, service, namespace, ingress, and egress communication paths. GKE uses NetworkPolicy enforcement to create pod level firewall rules that control which Pods and Services can communicate inside the cluster.

Pods in a GKE cluster can communicate freely with each other, which increases the risk that a compromised workload can reach unrelated applications or services in the same cluster. Default deny NetworkPolicies help establish namespace level segmentation by denying traffic unless a policy explicitly allows it. This supports defense in depth, multi-tenancy, and stronger separation between applications, environments, and teams.

NetworkPolicy enforcement must also be enabled through a supported GKE mechanism, such as GKE Dataplane V2 or Calico for Standard clusters. If no enforcing network plugin is configured, NetworkPolicy objects are not enforced, which means defined policies might not restrict traffic.

Solution

For noncompliant GKE Standard clusters, update the cluster build standard so a supported NetworkPolicy enforcement option is selected during cluster creation. Use GKE Dataplane V2 where possible, or Calico based NetworkPolicy enforcement where Dataplane V2 is not used. GKE Dataplane V2 is selected only during cluster creation, and existing clusters cannot be upgraded to use it.

-

Select GKE Dataplane V2 when creating new or replacement GKE Standard clusters, because NetworkPolicy enforcement is built into Dataplane V2.

-

For legacy datapath clusters, enable Calico based NetworkPolicy enforcement by enabling both the NetworkPolicy add-on and node enforcement.

-

Plan remediation during an approved maintenance window because enabling Calico based enforcement on existing legacy datapath clusters recreates nodes and can disrupt running workloads.

-

Confirm that workload NetworkPolicy objects are defined after enforcement is enabled, because enabling enforcement alone does not create traffic restrictions.

-

Validate the final configuration by confirming either ADVANCED_DATAPATH or networkPolicy.enabled=True, networkPolicy.provider=CALICO, and addonsConfig.networkPolicyConfig.disabled=False.

For legacy datapath clusters that use Calico, enable both required components:

gcloud container clusters update $CLUSTER_NAME \\
--location $LOCATION \\
--project $PROJECT_ID \\
--update-addons=NetworkPolicy=ENABLED

gcloud container clusters update $CLUSTER_NAME \\
--location $LOCATION \\
--project $PROJECT_ID \\
--enable-network-policy

Both the NetworkPolicy add-on and node enforcement are required for Calico based NetworkPolicy enforcement to function. For clusters already using ADVANCED_DATAPATH, do not run the Calico enablement commands because NetworkPolicy enforcement is built into GKE Dataplane V2.

Impact:

Default deny policies can immediately block workload communication that is not explicitly allowed, including application to application traffic, DNS, metadata server access, and required egress paths. Admins should identify required flows, define explicit ingress and egress allow rules, and validate connectivity before broad rollout. If Workload Identity Federation for GKE is used, egress to the metadata server must be allowed where required.

See Also

https://workbench.cisecurity.org/benchmarks/24956

Item Details

Category: SECURITY ASSESSMENT AND AUTHORIZATION, SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|CA-9, 800-53|SC-7, CSCv7|14.1, CSCv7|14.2

Plugin: GCP

Control ID: 47b81a13178c2c13e14dc0ac8e87af3d2e47589cea9392b4d63ea1e73ca6ad73