I have watched a platform engineer and a namespace owner argue about a single NetworkPolicy for the better part of an afternoon. Platform wanted a hard "no egress to the internet from any team namespace, full stop." The product team wanted their pod to keep reaching an external webhook that security had already cleared. Both had rights on the same object. Neither wanted to blink first.
Google Cloud is previewing something that reframes that argument. ClusterNetworkPolicy landed as a preview in GKE, per the post on the Google Cloud Blog. It is a cluster-scoped policy resource sitting one layer above the namespace-scoped NetworkPolicy most of us already know, and it introduces an ordering rule the older API never had.
What actually shipped
ClusterNetworkPolicy is a Kubernetes resource in the policy.networking.k8s.io API group, developed within the Kubernetes upstream community and, per Google Cloud, built with Cilium. The bit that matters to a platform team is not the group string. It is the shape the existing NetworkPolicy could not take: cluster-wide scope, plus a tier system that says, when two policies could apply to the same packet, which one is asked first.
How the tier stack decides
A ClusterNetworkPolicy declares itself in one of three tiers, and the order between them is fixed: Admin is evaluated first, then the standard NetworkPolicy layer your namespace owners already write into, then Baseline as the fallback.
Two useful things fall out of that.
First, an Admin policy can deny traffic and end the evaluation right there. That is the "floor" platform teams have been asking for. No namespace-scoped allow can override it, because the Admin tier ran first and said no.
Second, and this is the part I like, the Admin tier gets a Pass action alongside the usual accept and deny. Pass is a delegation verb. It says: I looked at this traffic, I decline to decide, hand it down to the next tier. That is how you build a policy that carves out narrow exceptions (say, "kube-system and shared-services can freely talk to each other") and then defers every other question to whatever the namespace teams have written locally.
The part namespace owners will actually like
Namespace-scoped NetworkPolicy keeps working. That sounds obvious, but plenty of "central network policy" solutions in the past made namespace policies feel decorative. Here the middle tier of the evaluation stack is literally the standard NetworkPolicy API. Nothing in a namespace has to change, and a developer who wants to let their pod reach a sidecar is still writing the same YAML they wrote yesterday.
If you have ever been in the meeting where the platform team announces they are "taking over network policy," you know why this matters. The floor moves up, the ceiling stays where the team owners left it, and the middle stays writable.
Rough edges I noticed
It is a preview and it looks like one. The API group is on an alpha version, which is the kind of number you re-read carefully before wiring it into a platform module you plan to keep around for a year. The feature also relies on a compatible dataplane, and Google Cloud is explicit that the GKE implementation was built with Cilium, so this is not a drop-in for every cluster shape.
The other rough edge is one Kubernetes always brings to policy work. Debugging a "packet dropped" now spans two API kinds and three tiers, and the tooling that tells you which rule bit you is only as good as the CNI's logs. Pass in particular is the primitive that will feel elegant in a design review and confusing at 2am, when the on-call has to reconstruct the whole evaluation chain from memory to answer "why is the checkout pod suddenly unable to reach Redis."
What I'm watching next
Two things. First, whether the Admin tier ships with a workable RBAC story on day one. Google Cloud's post gestures at role-based access to the tier itself, and if that lands cleanly it becomes a tidy split: platform SRE owns Admin and Baseline, product teams own NetworkPolicy, nobody argues about who edits which object. Second, how quickly the policy tooling (validators, linters, visualizers) learns to render a tier stack. Until it does, Pass will read like a coin flip on a code review.
If you run multi-tenant GKE and the "please stop overriding my egress lockdown" conversation happens more than once a quarter in your platform channel, this is worth trialling in a non-production cluster once your fleet has caught up. Tell me how the debugging story feels, because that is the part I cannot judge from the announcement alone.
Top comments (0)