Taking control of cluster security: A deep dive into GKE ClusterNetworkPolicy

Kubernetes traditionally left network security up to developers. Standard NetworkPolicy objects are scoped to namespaces, making it cumbersome to enforce global security policies across multiple teams and environments. ClusterNetworkPolicy, in Public Preview for GKE, introduces a cluster-wide resource to establish unchangeable security boundaries across the entire cluster.

This policy uses a sequential evaluation pipeline with three tiers: Admin, NetworkPolicy, and Baseline. In the Admin tier, administrators define mandatory rules that developers cannot override. The NetworkPolicy tier applies standard namespace-scoped policies, while the Baseline tier provides fallback default-deny policies for unhandled traffic.

Each tier uses explicit numeric priorities to determine rule precedence. Rules in a policy must either accept, deny, or pass traffic, with Pass allowing evaluation to continue in the next tier. For example, to isolate a sensitive namespace, an Admin tier policy can block all ingress and egress traffic to that namespace. Conversely, a Baseline tier default-deny policy ensures all traffic is blocked unless explicitly allowed in namespace-scoped policies.

This approach balances centralized compliance with developer flexibility. Implemented using Cilium, ClusterNetworkPolicy runs on GKE version 1.36.0 or later with Dataplane V2, limited to 100 ingress and 100 egress rules per policy. Monitoring and troubleshooting are available through GKE Dashboards.