# GKE previews ClusterNetworkPolicy for tiered cluster-wide network rules > ClusterNetworkPolicy enters preview in GKE 1.36 and later, separating administrator rules, namespace policies, and cluster-wide baseline defaults. Canonical URL: https://www.devobs.io/news/news-google-cloud-gke-clusternetworkpolicy/ By: Theo Morgan Published: 2026-09-06T11:58:54.636Z Updated: 2026-09-06T11:58:54.636Z Event date: 2026-08-11 Section: Infrastructure Google introduced ClusterNetworkPolicy in preview for GKE 1.36 and later on August 11, adding a cluster-wide resource for network rules. The [announcement](https://cloud.google.com/blog/products/networking/new-clusternetworkpolicy-in-gke) explains a three-tier evaluation order: administrator policy, namespace-level network policy, and a baseline that supplies defaults. ## Shared clusters get a policy hierarchy The change addresses a familiar ownership problem. Application teams need to define their own service connectivity, while platform administrators need rules that apply consistently across namespaces. Google describes an explicit pass action that delegates a decision down the hierarchy. This gives teams a way to distinguish an organizational requirement from an application-specific allowance. It also makes policy ordering part of the design, so reviewers must examine which tier owns a rule rather than reading each file in isolation. Network reachability is only one layer of a tenant boundary. An allowed connection should not automatically grant access to every object or API operation exposed by the destination. ## Migrate with observable decisions Begin by classifying existing rules into mandatory restrictions, essential platform connectivity, and application defaults. Avoid copying every namespace policy into the administrator tier: doing so would centralize configuration without clarifying responsibility. A useful pilot covers an allowed service call, a blocked cross-namespace connection, DNS resolution, and a developer policy that intentionally overrides a baseline. Verify the outcome at each tier and retain an explanation that an application owner can understand. Teams also need a rollout and recovery process for cluster-wide changes. A rule that applies everywhere has a different blast radius from one namespace’s configuration. The immediate opportunity is a clearer separation of duties. The adoption test is whether administrators can enforce required boundaries while developers can still diagnose and operate legitimate service communication. ## Source references -