GKE ClusterNetworkPolicy adds cluster-wide, tiered network guardrails in public preview

A cluster-scoped policy for GKE

Google Kubernetes Engine has a new cluster-scoped network policy resource, ClusterNetworkPolicy, currently in Public Preview. According to a Google Cloud post on dev.to, it lets platform and security teams define traffic rules that span every namespace in a cluster and that namespace-level policies cannot override.

The problem it addresses

Standard Kubernetes NetworkPolicy objects are scoped to a single namespace, and when multiple policies select the same pod their effects are additive: traffic is allowed if any one policy permits it. That model works for isolating microservices within one application, the post explains, but it leaves cluster administrators without a native mechanism for global guardrails. Blocking every pod from reaching the cloud metadata server, or completely isolating one namespace from the rest, has so far required complex policy engines, custom admission controllers, or automation that injects namespace-scoped policies — approaches the post characterizes as fragile and hard to audit.

A three-tier evaluation pipeline

Unlike the additive namespace model, ClusterNetworkPolicy is evaluated as a strict sequential pipeline in which the first matching rule wins. Traffic moves through three tiers in order:

• Admin tier: evaluated first. This is where administrators place mandatory rules that developers cannot bypass, and a matching Accept or Deny verdict stops evaluation immediately.
• NetworkPolicy tier: traffic not decided in the Admin tier is checked against ordinary namespace-scoped NetworkPolicy resources configured by developers and DevOps teams.
• Baseline tier: fallback rules for traffic that no namespace policy matched, such as a cluster-wide default-deny posture that developers can choose to override in their own namespaces.

If a packet matches no rule in any tier, GKE falls back to its default behavior of implicitly allowing it. Within each tier, policies are ordered by a numeric priority from 0 to 1000, where lower numbers take precedence, and rules inside a single policy are evaluated top to bottom.

Three verdicts, including Pass

Every rule carries one of three actions. Deny blocks the traffic and Accept permits it, and both short-circuit the pipeline. Pass hands the decision to the next tier. The post highlights Pass as the key delegation mechanism: an administrator can match a specific flow — for instance web traffic on port 8080 — skip the remaining Admin-tier rules, and let the namespace owner decide. If a namespace policy accepts the traffic, it flows; if none exists, evaluation continues to the Baseline tier. This, the post argues, balances centralized compliance with developer agility.

What the example policies show

Two patterns illustrate the design. The first is a global deny placed in the Admin tier that selects a namespace labeled sensitive-ns and denies all ingress and egress to and from any other namespace — a boundary no developer-created policy can relax. The second is a default-deny rule in the Baseline tier covering all namespaces. A developer who needs ingress to a frontend service from an external ingress controller can simply deploy a standard namespace-scoped NetworkPolicy; because the NetworkPolicy tier runs before the Baseline tier, the traffic is permitted without platform admin involvement.

Requirements and limits

The implementation is built entirely on open-source Cilium. Google backported the support to Cilium 1.19 for GKE clusters, and the upstream capability is expected to be generally available to the broader open-source ecosystem starting with Cilium 1.20. Clusters must run GKE version 1.36.0-gke.4447000 or later and use Dataplane V2. As a preview feature, a single ClusterNetworkPolicy object is limited to 100 ingress rules and 100 egress rules, and traffic verdicts can be monitored and troubleshot through GKE Dataplane V2 observability tooling.

Why it matters

ClusterNetworkPolicy separates cluster-wide guardrails from namespace-level configuration, giving security teams enforcement power they previously had to assemble from fragile automation. The tiered model with the Pass action means compliance rules and developer flexibility no longer compete: administrators set hard boundaries or sensible defaults, while teams keep day-to-day control over their own namespaces. The Cilium foundation also signals that this hierarchical policy model may spread beyond GKE into the wider Kubernetes ecosystem once it lands upstream in Cilium 1.20, making it worth understanding even for teams not on Google Cloud. Anyone evaluating it today should treat it as a preview, with the stated rule limits and version requirements in mind.