Google Brings Cluster-Wide Network Security Governance to GKE with ClusterNetworkPolicy

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.

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.

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:

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.

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.