GKE’s ClusterNetworkPolicy: Cluster-Wide Security Without the Headaches

Managing network security in a multi-tenant Kubernetes environment is like herding capybaras through a swamp—you need to keep everyone moving together without letting any rogue caiman sneak in. Developers want their microservices to chat freely, while platform and security teams need to enforce compliance and prevent lateral movement. The old standard, Kubernetes NetworkPolicy, works fine for single-namespace isolation but falls short when you need cluster-wide guardrails.

Enter ClusterNetworkPolicy (CNP), now in preview on GKE (version 1.36+). It’s an open-source standard from the Kubernetes SIG-Policy Working Group, designed to give admins a centralized, non-bypassable way to manage network security across the entire cluster. Think of it as the alpha capybara that keeps the whole herd in line.

Why CNP? Because Flat Policies Are a Mess

Standard NetworkPolicy is scoped to individual namespaces and built for developer self-service. When admins try to use it for global enforcement, you get policy conflicts and operational headaches. CNP fixes this with a hierarchical tier system that evaluates policies in a deterministic, top-to-bottom order:

1. Admin tier: Highest precedence. Enforced before anything else—perfect for compliance mandates.
2. Network policy tier: The standard namespace level where developers manage their app-specific policies.
3. Baseline tier: Lowest precedence, setting the cluster’s default behavior (like a deny-all zero-trust posture) that can be overridden by namespace policies.

This structure aligns network security with organizational roles. Using RBAC, you can let the admin tier enforce non-negotiable rules, while platform teams set baseline defaults, and developers still have freedom within their namespaces—without stepping on each other’s toes.

Real-World Scenarios Where CNP Shines

Here are a few common use cases where CNP turns complex security requirements into centralized, manageable rules:

• Isolating sensitive workloads: Apply an admin-tier deny rule to namespaces handling payment or compliance data, overriding any permissive developer policies that might expose them.
• Protecting core services: Create an admin-tier allow rule for critical services like kube-dns, ensuring they stay accessible even if a namespace policy goes haywire.
• Managing external egress: Use IP range matching to control egress at the cluster level—restrict or permit access to corporate intranets or external IPs, guarding against data exfiltration.

Example: A Platform Guardrail in Action

Imagine you need all workloads to reach shared authentication and telemetry services, but block access to a restricted vault namespace. With CNP, a platform admin defines a single admin-tier policy:

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:
    - name: allow-shared-services
      action: Accept
      to:
      - namespaces:
          matchLabels:
            kubernetes.io/metadata.name: shared-services
    - name: block-restricted-vault
      action: Deny
      to:
      - namespaces:
          matchLabels:
            kubernetes.io/metadata.name: restricted-vault
    - name: delegate-remaining-egress
      action: Pass
      to:
      - namespaces: {}
      - networks:
        - 0.0.0.0/0
        - ::/0

Notice the Pass action—it lets the admin tier inspect traffic and then hand off the final accept/deny decision to developer namespace policies. That’s central oversight without micromanaging every pod.

Built on Open Source, Ready for the Real World

Instead of a proprietary lock-in, Google worked with the Kubernetes community to design the CNP API (policy.networking.k8s.io) and collaborated with the Cilium community on its implementation. That means your security configs stay portable across environments—no vendor swamp traps.

CNP on GKE shifts network security from namespace-scoped rules to unified, cluster-wide governance. It’s currently in preview in GKE 1.36 and later. For more details, check out the GKE documentation and the Kubernetes API spec.

If you’re comparing platforms, our Google Cloud review covers the broader ecosystem, and for other backend options, see our Supabase review or Firebase review.

Original announcement published on Google Cloud.