# GKE Cluster Network Policy Not Enforced

> ZopNight rule RC-125 fires when a GKE cluster's networkPolicy config reads disabled, leaving pod-to-pod traffic unrestricted. A single compromised container can reach every service in the cluster. Detection uses the discoverer's explicit network_policy_enabled=false stamp, never absence. Enabling enforcement on an existing cluster requires node pool recreation.

Source: https://zop.dev/integrations/gcp/recommendations/gke-cluster-network-policy-not-enforced
Updated: 2026-08-19

---

## One compromised pod, then the whole cluster

Inside a GKE cluster without NetworkPolicy enforcement, the pod network is flat: any pod can open a connection to any other pod or service, across every namespace. VPC firewall rules do not help: they govern traffic at the node and network edge, not pod-to-pod flows inside the cluster. So the blast radius of a single compromised container is the entire cluster interior: the attacker's next hop is your database proxy, your internal admin service, or the metadata of a more privileged workload, with nothing in the path to say no. Namespaces feel like boundaries but enforce none; without a policy engine they are naming conventions.

## How the rule knows, precisely

The discoverer derives `network_policy_enabled` from the cluster's `networkPolicy` configuration and writes it in both polarities, so rule RC-125 proves the condition: it fires only on an explicit `false` and abstains when the value is absent or unparseable. An earlier revision of this rule keyed off a tag no producer wrote, which made it fire on every cluster. The current gate is the opposite failure posture, firing on confirmed evidence only. Reproduce the read yourself:

```bash
gcloud container clusters describe my-cluster --location us-central1 \
  --format='value(networkPolicy.enabled)'
```

## Why remediation is priced in node pools

Enabling the NetworkPolicy enforcer on an existing cluster is not a checkbox. GKE requires node pool recreation to roll the enforcement dataplane onto the nodes, which means draining and replacing every node under production traffic. On a routes-based cluster it is worse: NetworkPolicy needs VPC-native networking, so that cluster is looking at a full rebuild. Budget the change as a maintenance operation, not a config tweak. New clusters get it at creation with `--enable-network-policy` for free.

## Enforcement enabled is not policy written

An enabled enforcer with zero NetworkPolicy objects still allows everything; the finding closes but the exposure remains. The working pattern: apply a default-deny policy per namespace, then add narrowly scoped allow rules for each required path, starting with the namespaces that hold credentials or customer data. Roll namespace by namespace and watch for broken flows; the first default-deny always finds an undocumented dependency.