--- url: "https://xcademia.com/news/google-brings-cluster-wide-network-security-governance-to-gke-with-clusternetworkpolicy" title: "Google Brings Cluster-Wide Network Security Governance to GKE with ClusterNetworkPolicy" description: "Google Cloud brings ClusterNetworkPolicy to GKE, adding tiered cluster-wide network security controls while preserving developer namespace-level autonomy." publishedAt: "2026-08-11T06:08:32.858+00:00" updatedAt: "2026-08-11T06:10:39.881496+00:00" type: news category: "cloud-security" source_name: "Google Cloud Blog - ClusterNetworkPolicy in GKE" source_url: "https://cloud.google.com/blog/products/networking/new-clusternetworkpolicy-in-gke" tags: - "#GoogleCloud" - "#GKE" - "#Kubernetes" - "#ClusterNetworkPolicy" - "#CloudSecurity" - "#NetworkSecurity" - "#ZeroTrust" - "#DevSecOps" --- # Google Brings Cluster-Wide Network Security Governance to GKE with ClusterNetworkPolicy > Google Cloud is bringing ClusterNetworkPolicy to GKE, giving platform and security teams cluster-wide controls while allowing developers to retain namespace-level autonomy for microservices. Source: **Google Cloud Blog - ClusterNetworkPolicy in GKE** · 11 August 2026 ## Introduction Google Cloud is introducing **ClusterNetworkPolicy (CNP)** to Google Kubernetes Engine (GKE), adding a cluster-wide approach to Kubernetes network security that is designed to balance central governance with developer autonomy. The announcement, published by Google Cloud on August 10, 2026, focuses on a common challenge in multi-tenant Kubernetes environments: developers need flexibility to connect their microservices, while platform and security teams need consistent controls to enforce security requirements, reduce lateral movement and establish cluster-wide guardrails. Google says ClusterNetworkPolicy is currently available in **preview for GKE version 1.36 and later**. The API is based on an open-source standard developed through the Kubernetes SIG-Policy Working Group, with implementation work involving the Cilium community. ## Why standard Kubernetes NetworkPolicy can become difficult at cluster scale Kubernetes already provides the `NetworkPolicy` resource for controlling traffic between workloads. These policies are namespace-scoped and are useful when individual development teams need to define communication rules for their applications. The challenge becomes more complex when platform administrators need to establish security requirements that apply across an entire cluster. Google Cloud describes this as a tension between two operating models: - Developers need application-level control over microservice communication. - Platform teams need consistent cluster-wide security controls. - Security teams need policies that cannot simply be bypassed by a permissive application policy. - Organisations need a predictable way to resolve policy conflicts. ClusterNetworkPolicy addresses this by introducing a cluster-wide resource with hierarchical policy evaluation. ## A three-tier model for Kubernetes network policy One of the key ideas behind ClusterNetworkPolicy is its **tiered policy structure**. Instead of treating policies as a flat collection of potentially conflicting rules, CNP evaluates them from higher to lower precedence. **1. Admin tier** The Admin tier has the highest precedence. Policies placed here are evaluated before policies in the lower tiers. This provides a mechanism for security and platform administrators to establish mandatory controls. **2. Network Policy tier** This is the conventional namespace-level policy layer where developers can define application-specific communication rules. **3. Baseline tier** The Baseline tier provides lower-precedence cluster-wide defaults. Google describes this as a place where platform teams can establish default behaviour, including a deny-all security posture, while namespace-level policies can override those baseline rules. ![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1786428103173-info1--27-.webp) ## Deterministic policy evaluation The tier system is important because it provides a predictable way to handle competing security requirements. The Admin tier also introduces an explicit `Pass` action. This gives administrators another option besides accepting or denying traffic. For example, a security team can use an Admin policy to inspect traffic against a mandatory global rule and then use `Pass` to delegate the final decision to the relevant namespace-level policy. This creates a separation between **central security governance** and **application-specific policy management**. In practical terms, the model can be viewed as: ``` ClusterNetworkPolicy | v +-------------+ | Admin Tier | +-------------+ | Accept / Deny / Pass | v +------------------+ | Network Policy | | Developer Rules | +------------------+ | v +-------------+ | Baseline | +-------------+ ``` This structure is particularly relevant in environments where multiple teams share the same Kubernetes cluster. ## Protecting sensitive workloads One of the use cases highlighted by Google Cloud is workload isolation. An organisation may have namespaces containing sensitive applications or regulated data. A platform administrator can establish an Admin-tier rule that prevents other workloads from reaching those namespaces. Because the rule is placed at the Admin tier, a more permissive namespace-level policy cannot simply override that global restriction. This can be useful for environments where application teams have significant autonomy but certain security boundaries must remain centrally enforced. ### Protecting critical cluster services ClusterNetworkPolicy can also be used in the opposite direction. Administrators can establish global allow rules for services that must remain accessible, such as `kube-dns`. The purpose is to prevent application-level policy mistakes from unintentionally disrupting critical internal services. This reflects a broader principle in Kubernetes security: central policies can establish minimum requirements while developers continue to manage the normal communication patterns of their workloads. ## Controlling external egress Another important scenario is outbound traffic. ClusterNetworkPolicy can use IP address range matching to control egress at the cluster level. This can allow administrators to restrict or permit communication with corporate networks or external IP ranges. For security teams, this provides another mechanism for controlling where workloads can send traffic and can serve as a safeguard against unauthorised data movement. ![info-2](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1786428133263-info2--27-.webp) ## A practical ClusterNetworkPolicy example Google Cloud provides an example based on a common enterprise scenario. Application workloads across multiple namespaces need access to shared platform services, such as authentication and telemetry infrastructure. At the same time, they must not be able to access a restricted vault namespace. All other traffic is delegated to developer-managed namespace policies. The central policy can be structured as follows: ``` apiVersion: policy.networking.k8s.io/v1alpha2 kind: ClusterNetworkPolicy metadata: name: platform-isolation-guardrail spec: tier: Admin priority: 10 subject: namespaces: matchExpressions: - key: kubernetes.io/metadata.name operator: NotIn values: - kube-system - shared-services - restricted-vault egress: # 1. Allow access to shared platform services - name: allow-shared-services action: Accept to: - namespaces: matchLabels: kubernetes.io/metadata.name: shared-services # 2. Block access to the restricted vault - name: block-restricted-vault action: Deny to: - namespaces: matchLabels: kubernetes.io/metadata.name: restricted-vault # 3. Delegate remaining traffic # to developer namespace policies - name: delegate-remaining-egress action: Pass to: - namespaces: {} - networks: - 0.0.0.0/0 - ::/0 ``` The important part of this example is the combination of `Accept`, `Deny` and `Pass`. `Accept` establishes a mandatory allow rule for shared services. `Deny` establishes a mandatory restriction against the sensitive vault namespace. `Pass` delegates the remaining traffic decision to lower-level policies. This allows one centrally managed policy to establish the non-negotiable security boundaries without attempting to define every application communication rule itself. ### What the example means operationally The policy targets application tenant namespaces while excluding: - `kube-system` - `shared-services` - `restricted-vault` For traffic going to `shared-services`, the Admin-tier policy returns `Accept`. For traffic going to `restricted-vault`, it returns `Deny`. For other destinations, the policy returns `Pass`, allowing the decision to continue to the relevant namespace-level policies. This separation is important because a central security policy does not necessarily need to describe every connection in the cluster. Instead, it can define the boundaries that must always apply and allow application teams to manage the remaining traffic. ## Open-source foundations and portability Google Cloud says ClusterNetworkPolicy is based on an open-source API rather than being implemented as a proprietary extension. The API uses the `policy.networking.k8s.io` API group, distinguishing it from the namespace-scoped Kubernetes `NetworkPolicy` API under `networking.k8s.io`. Google also says it worked with the Cilium community on implementation of the API. This open-source approach is significant for organisations operating Kubernetes across different environments. Google positions the API as a way to keep security configuration more portable while providing the cluster-wide governance required by platform teams. ## ClusterNetworkPolicy versus traditional NetworkPolicy The distinction can be summarised simply: Capability Kubernetes NetworkPolicy ClusterNetworkPolicy Primary scope Namespace Cluster Developer management Yes Can coexist with developer policies Central administration Limited by namespace scope Designed for cluster-wide governance Explicit Deny Standard NetworkPolicy is allow-oriented Supports explicit `Deny` Policy tiers No Admin, Network Policy and Baseline `Pass` action No Supported in Admin tier Cluster-wide guardrails Not its primary model Core use case Multi-team policy evaluation More difficult to centralise Deterministic tiered evaluation The two approaches are therefore not necessarily competing technologies. ClusterNetworkPolicy is designed to provide a higher-level governance layer while standard namespace policies continue to support application-specific controls. ![info-3](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1786428152791-info3--25-.webp) ## What this means for Kubernetes platform teams The introduction of ClusterNetworkPolicy reflects a broader challenge in modern Kubernetes operations: security requirements increasingly need to operate at the same scale as the infrastructure. A cluster may contain many namespaces, applications and development teams. Giving every team complete control over network policy can make central enforcement difficult, while attempting to manage every application rule centrally can create an operational burden. The tiered model provides another approach. Platform teams can establish baseline requirements. Security teams can define mandatory Admin-tier restrictions. Developers can continue to manage application-specific NetworkPolicies within their namespaces. For enterprises, this could mean a clearer separation of responsibilities between security governance and application operations. The announcement highlights a broader industry shift toward **policy-based infrastructure governance**, where security controls are designed to work across distributed teams without eliminating developer self-service. ## Security considerations ClusterNetworkPolicy can strengthen the structure of network governance, but policy design remains important. Administrators still need to understand application dependencies, namespace boundaries, service requirements and legitimate external communication. A poorly designed policy can still affect application connectivity. Google Cloud's current documentation recommends using network policy logging to audit and troubleshoot policy behaviour. GKE can generate Cloud Logging records for connections allowed or denied by network policies, helping teams understand the practical effects of their configurations. This means deployment should be accompanied by testing, monitoring and policy review rather than treated as a one-time configuration exercise. ## Availability Google Cloud says **ClusterNetworkPolicy is currently in preview for GKE version 1.36 and later**. The company directs users to its GKE ClusterNetworkPolicy configuration documentation and the Kubernetes SIG-Network ClusterNetworkPolicy API specification for implementation details. Additional details were not disclosed in the announcement regarding a general availability date. ## The bigger picture ClusterNetworkPolicy moves GKE network security from a primarily namespace-oriented model toward a more structured cluster-wide governance approach. The key idea is not to replace developer-managed network policies, but to introduce higher-level controls that security and platform teams can use to establish mandatory boundaries. For organisations operating multi-tenant Kubernetes environments, the combination of **Admin, Network Policy and Baseline tiers**, together with **Accept, Deny and Pass** actions, provides a more explicit framework for separating central security responsibilities from application-level policy management. The development reflects growing demand for Kubernetes platforms that can support both operational autonomy and central security governance as cloud-native environments become increasingly complex. ## Original source https://cloud.google.com/blog/products/networking/new-clusternetworkpolicy-in-gke ## Tags `#GoogleCloud` · `#GKE` · `#Kubernetes` · `#ClusterNetworkPolicy` · `#CloudSecurity` · `#NetworkSecurity` · `#ZeroTrust` · `#DevSecOps` --- ## About this content This Markdown news article is the citation-grade twin of [Google Brings Cluster-Wide Network Security Governance to GKE with ClusterNetworkPolicy](https://xcademia.com/news/google-brings-cluster-wide-network-security-governance-to-gke-with-clusternetworkpolicy). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite. When citing or quoting, please attribute *Xcademia* and link back to the source URL above. - Source: https://xcademia.com/news/google-brings-cluster-wide-network-security-governance-to-gke-with-clusternetworkpolicy - Publisher: Xcademia — https://xcademia.com - Catalogue index: https://xcademia.com/llms-full.txt