Google Kubernetes Engine now supports ClusterNetworkPolicy, a cluster-wide resource that enforces network security through a deterministic tiered hierarchy: admin tier for compliance guardrails, network policy tier for developer self-service, and baseline tier for default cluster behavior. This structure prevents policy conflicts by evaluating rules top-down, allowing security teams to mandate access to shared services or block sensitive namespaces while delegating remaining traffic to namespace-scoped policies. The API is open-source, built with Kubernetes SIG-Policy and Cilium, and available in preview on GKE version 1.36 and later.
How tiered evaluation resolves policy conflicts
ClusterNetworkPolicy introduces three tiers: Admin, Network Policy, and Baseline. The Admin tier has highest precedence and is evaluated first, allowing platform and security teams to enforce non-bypassable rules such as global deny lists for sensitive workloads or mandatory allow lists for core services like kube-dns. This ensures compliance mandates cannot be overridden by developer policies, providing a strong foundation for cluster-wide security governance.
The Network Policy tier corresponds to standard Kubernetes NetworkPolicy resources, where developers define namespace-scoped rules for their applications. These policies are evaluated only after Admin tier rules, meaning they can refine traffic flow within the boundaries set by administrators but cannot bypass admin-enforced guardrails. This preserves developer autonomy for application-specific communication while maintaining global security controls.
The Baseline tier has lowest precedence and defines the cluster’s default behavior when no other policies match. It can be used to implement a zero-trust 'deny-all' posture across the cluster, which namespace policies can then selectively override for specific workloads that require access. This tier ensures there is always a defined fallback state, preventing unintended openness when no explicit rules apply.
Common use cases for centralized network security
Isolating sensitive workloads: Administrators can apply an Admin tier rule to deny all egress from namespaces containing payment processing or compliance data, overriding any permissive developer policies that might accidentally expose these environments. This creates a reliable isolation boundary that cannot be altered by application teams, ensuring critical data remains protected regardless of local misconfigurations.
Protecting core services: By creating an Admin tier allow rule for critical services such as kube-dns or shared telemetry platforms, administrators ensure these components remain accessible even if a developer misconfigures a namespace policy to block them. This prevents operational disruption from well-intentioned but incorrect local policies, maintaining essential service availability across the cluster.
Managing external egress: Using IP range matching in Admin tier egress rules, teams can restrict or permit traffic to corporate intranets or external IP blocks at the cluster level. This prevents data exfiltration and enforces network segmentation without relying on per-namespace configurations, providing a centralized control point for traffic leaving the cluster boundary.
Example: Platform isolation guardrail in practice
A platform administrator wants to allow all application namespaces to reach shared services (like authentication and telemetry) while blocking access to a restricted vault namespace, and delegating all other traffic decisions to developer policies. This is achieved with a single ClusterNetworkPolicy in the Admin tier, demonstrating how centralized rules can enforce complex organizational requirements.
The policy uses namespace label matching to target all namespaces except kube-system, shared-services, and restricted-vault. It includes three egress rules: one Accept rule for shared-services, one Deny rule for restricted-vault, and a final Pass rule with action: Pass for all other traffic (0.0.0.0/0 and ::/0), which delegates evaluation to the Network Policy tier. This structure ensures platform requirements are met while preserving developer autonomy for internal communication.
This Pass action is key: it signals that the Admin tier has completed its inspection and allows the final Accept/Deny decision to be made by developer-defined namespace policies. This enables centralized oversight without removing developer agency over internal service communication, striking a balance between security governance and operational flexibility that development teams require.
What to do next
ClusterNetworkPolicy is now in preview on GKE clusters running version 1.36 or later. To get started, review the GKE documentation on configuring ClusterNetworkPolicy and the upstream Kubernetes SIG-Network API specification. Begin by defining Admin tier guardrails for your most critical compliance requirements, such as blocking access to sensitive namespaces or mandating access to shared infrastructure, then validate that developer policies continue to function as expected within those boundaries.
Source: ClusterNetworkPolicy in GKE: Balancing control and autonomy for your microservices (GCP).
