SecurityBrief New Zealand - Technology news for CISOs & cybersecurity decision-makers
New Zealand
Google adds cluster-wide network policy to GKE preview

Google adds cluster-wide network policy to GKE preview

Tue, 11th Aug 2026 (Today)
Sean Mitchell
SEAN MITCHELL Publisher

Google has added ClusterNetworkPolicy to Google Kubernetes Engine, with the feature available in preview for version 1.36 and later.

The addition brings a cluster-wide network security control to Kubernetes environments shared by multiple teams. It is intended for administrators who need to apply rules across an entire cluster, rather than relying only on namespace-level controls managed by developers.

Standard Kubernetes NetworkPolicy is commonly used to manage traffic between workloads, but it is limited to individual namespaces. That structure supports developer self-service, but it can create conflicts when security or platform teams try to enforce broader controls across a cluster.

ClusterNetworkPolicy is an open-source standard developed through the Kubernetes SIG-Policy Working Group. In GKE, it gives administrators a central way to apply non-bypassable rules while allowing development teams to manage application-specific policies within their own namespaces.

Tiered rules

A central part of the model is a hierarchical tier system that evaluates policies from the top down. The highest level is the admin tier, followed by the standard namespace network policy tier, and then a baseline tier that sets default behaviour when no other policy applies.

The structure is designed to reflect organisational responsibilities. Security teams can use the admin tier for compliance rules, platform teams can apply a baseline deny-all stance across a cluster, and developers can continue writing standard namespace rules for their own services.

The model also includes a Pass action in the admin tier. This lets central teams inspect traffic against global rules, then leave the final allow-or-deny decision to namespace-level policies where appropriate.

Common uses

Google highlighted several uses for the new control. One is isolating sensitive workloads, such as payment processing or compliance-related data, by applying a global deny rule that overrides permissive namespace policies.

Another is protecting core services such as kube-dns with a global allow rule, ensuring they remain reachable even if a namespace policy is misconfigured. Administrators can also manage external egress traffic at cluster level by matching IP address ranges to restrict or allow access to company networks or external destinations.

Google also outlined a scenario in which application workloads across namespaces are allowed to reach shared authentication and telemetry services, while access to a restricted vault namespace is blocked. In that setup, remaining traffic can be delegated back to developer-managed namespace policies through the Pass action.

Open-source basis

Google said it worked with the Kubernetes community on the ClusterNetworkPolicy API rather than building the feature as a proprietary extension. The API uses the policy.networking.k8s.io group, separating it from the existing namespace-scoped NetworkPolicy API under networking.k8s.io.

It also worked with the Cilium community on an implementation of the API. By basing the feature on an open-source standard, Google said security configurations can remain portable across different environments.

The introduction reflects a broader shift in Kubernetes operations as organisations try to impose central controls on shared infrastructure without removing autonomy from application teams. In multi-tenant environments, that balance has become harder to maintain as more services, namespaces and compliance requirements are added to the same cluster.

Cluster-wide policy tools have drawn attention because they address a gap between developer-focused controls and platform-wide governance. The tiered approach in ClusterNetworkPolicy is intended to make policy evaluation more predictable by reducing the chance that overlapping rules from different teams will clash unexpectedly.

For GKE users, the feature adds another layer to Google's managed Kubernetes service at a time when customers are placing greater scrutiny on internal segmentation and east-west traffic controls. The preview release makes the feature available for testing in newer GKE versions while the standard continues to develop in the open-source community.