Managing network security in a multi-tenant Kubernetes environment typically requires balancing two distinct needs: developers need their microservices to communicate effectively, while platform and security teams must maintain compliance, prevent lateral movement, and establish cluster-wide guardrails.
Historically, the standard Kubernetes NetworkPolicy has been the primary tool for this. While effective for single-namespace isolation, standard NetworkPolicy is scoped strictly to individual namespaces and designed around developer self-service. When cluster administrators attempt to use it for global security enforcement, it can lead to policy conflicts and operational challenges.
To address this, we introduced ClusterNetworkPolicy (CNP), an open-source standard developed by the Kubernetes SIG-Policy Working Group (WG), to Google Kubernetes Engine (GKE). Designed for scale, CNP is a cluster-wide resource that allows administrators to manage network security centrally, providing a mechanism for those responsible for global security to implement consistent, non-bypassable policies.
Read on for technical details about CNP, some common use cases, an example policy, and how to get started.
Structuring policies with tiers
A core capability of ClusterNetworkPolicy is its hierarchical tier system. Rather than attempting to reconcile flat, conflicting peer rules simultaneously, CNP establishes a deterministic, top-to-bottom evaluation hierarchy:
-
The admin tier: The highest precedence level. Rules here are enforced before any other policies.
-
The network policy tier: The standard namespace level, where developers manage their specific application policies.
-
The baseline tier: The lowest precedence, establishing the cluster’s default behavior when no other policies apply. This can be overridden using namespace scoped policies.
This tiered structure helps align network security with organizational roles. Using standard role-based access control (RBAC), you can manage the admin tier to enforce compliance mandates, while platform teams can use the baseline tier to set a default “deny-all” zero-trust posture across the cluster. At the same time, developers can write standard network policies for their applications without overriding core security mandates.
This deterministic, top-to-bottom evaluation method resolves conflicts between different teams’ policies. The admin tier introduces an explicit Pass action. This allows security teams to inspect traffic against global rules and then delegate the final Accept or Deny decision down to the developer’s namespace policy, facilitating both central oversight and distributed management.
Common network security scenarios
This tiered architecture translates complex security requirements into centralized rules. Here are common scenarios where ClusterNetworkPolicy provides a practical solution:
-
Isolating sensitive workloads: You can apply an admin-tier global deny rule to isolate specific namespaces — such as those used for payment processing or compliance data — from the rest of the cluster. This action overrides any permissive developer policies that might otherwise expose these environments.
-
Protecting core services: To prevent configurations that might disrupt internal operations, administrators can create an admin-tier global allow rule for critical services like kube-dns. This allows these services to remain accessible regardless of any misconfigured namespace policies.
-
Managing external egress: By utilizing IP address range matching, egress traffic can be controlled at the cluster level. This functionality allows you to explicitly restrict or permit access to corporate intranets or external IP ranges, serving as a safeguard against unauthorized data exfiltration.
Example scenario
Consider a common enterprise requirement: Application workloads across all namespaces must be permitted to reach central platform infrastructure (such as shared authentication and telemetry services), while access to sensitive environments — like a restricted vault namespace — is strictly prohibited. Meanwhile, routine microservice traffic is delegated to developer-managed, namespace-scoped policies.
ClusterNetworkPolicy makes this straightforward. A platform administrator simply defines an admin-tier guardrail centrally:
- code_block
- <ListValue: [StructValue([('code', 'apiVersion: policy.networking.k8s.io/v1alpha2rnkind: ClusterNetworkPolicyrnmetadata:rn name: platform-isolation-guardrailrnspec:rn tier: Adminrn priority: 10rn subject:rn # Target all application tenant namespaces, excluding system and core infrastructurern namespaces:rn matchExpressions:rn – key: kubernetes.io/metadata.namern operator: NotInrn values: ["kube-system", "shared-services", "restricted-vault"]rn egress:rn # 1. Mandate access to central shared platform servicesrn – name: allow-shared-servicesrn action: Acceptrn to:rn – namespaces:rn matchLabels:rn kubernetes.io/metadata.name: shared-servicesrnrn # 2. Enforce strict block on accessing the restricted vault namespacern – name: block-restricted-vaultrn action: Denyrn to:rn – namespaces:rn matchLabels:rn kubernetes.io/metadata.name: restricted-vaultrnrn # 3. Explicitly delegate all remaining traffic to developer namespace policiesrn – name: delegate-remaining-egressrn action: Passrn to:rn – namespaces: {}rn – networks:rn – 0.0.0.0/0rn – ::/0'), ('language', ''), ('caption', )])]>
Extending open-source foundations
Instead of building this functionality as proprietary extensions, we worked with the Kubernetes community to design the ClusterNetworkPolicy API (policy.networking.k8s.io), distinguishing it from the namespace-scoped NetworkPolicy API (networking.k8s.io). Furthermore, we collaborated closely with the Cilium community to build its implementation of the API.
Because it is built on open-source standards, GKE helps ensure that security configurations remain portable across different environments. The ClusterNetworkPolicy API natively supports tier selection, enabling clear and deterministic policy evaluation. This approach lets administrators enforce robust security guardrails while maintaining the operational flexibility that development teams depend on.
ClusterNetworkPolicy on GKE elevates workload network security — shifting operations from namespace-scoped rules to unified, cluster-wide governance. It is currently in preview in version 1.36 and later. To learn more and get started, check out: