Build1 distinct publisher2 min readPublished
Google's preview cluster-scoped policy gives platform teams a rule namespace owners cannot override. What it does not give them is a cluster that denies by default.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Type `Admin` in the tier field and the rule holds against anything a namespace owner writes. Type `Baseline` and the identical rule text becomes a default that those same owners may override inside their own namespace [8][9]. One word decides whether a manifest is a control or a suggestion, and nothing else in the file looks any different.
The delegation case is more interesting than the lockdown case. The worked example is web traffic on port 8080: an Admin rule matches the flow, uses `Pass` to skip the remainder of the Admin tier, and hands the verdict to namespace-scoped policy; if the namespace has written no policy, the flow carries on to Baseline [13]. That is a contract rather than a hole. The admin is stating which ports are the application team's business, in an object the application team cannot edit.
Then the arithmetic that decides whether any of this stays maintainable. Priorities run 0 to 1000 within a tier, lower numbers evaluated first, and rules inside a single policy run top to bottom [11]. The sample policy that isolates a sensitive namespace sits at priority 10 [14], which leaves exactly ten values above it [15]. That is adequate for a demo and thin for a cluster where two teams each believe their rule goes first, because the tier is a strict sequence and the first match ends it [6]. Numbering convention is cheap to agree on now and expensive to retrofit once a compliance rule is already in production at priority 10.
The other thing worth reading closely is what the old pattern was actually failing at. Injecting namespace-scoped policies was fragile because it depended on a controller continuing to write objects into every namespace that existed, forever, and because those namespace policies are additive: if several select a pod, permission from any one of them is enough [2][3]. So an administrator writing in that layer was competing with developers on equal terms. The Admin tier removes the competition by changing evaluation order, not by taking away the developers' verbs.
One caution on shelf life. The manifests carry `apiVersion: policy.networking.k8s.io/v1alpha2` [14] and the feature is in public preview [5]. A boundary expressed as a single cluster-scoped object is easier to audit than a controller's output, but it is also pinned to an API version that has not settled, and teams generating these objects from something they own will pay less than teams hand-editing them if the field names move.
Ranked by verification strength, evidence, and original report placement.
GKE ClusterNetworkPolicy, currently in Public Preview, is a cluster-scoped resource that lets security and platform teams establish non-overridable security boundaries across the entire cluster, spanning all namespaces.
Traffic flows through three policy tiers in order: Admin tier, then the namespace-scoped NetworkPolicy tier, then Baseline tier.
Admin tier policies are evaluated first and hold mandatory guardrails developers cannot bypass; if an Admin rule matches with an Accept or Deny verdict, evaluation stops immediately.
In the Baseline tier, administrators can define fallback policies such as a default-deny posture, which developers can choose to override in their respective namespaces.
Standard Kubernetes NetworkPolicy objects are namespace-scoped.
Namespace-scoped NetworkPolicy resources are additive: if multiple policies select a pod, traffic is allowed if any policy permits it.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but single-sourced and vendor-authored
The mechanics are unusually specific for a single source: named tiers and their order, first-match-wins semantics, a 0-1000 priority range, three rule actions, two complete manifests at policy.networking.k8s.io/v1alpha2, explicit version and dataplane prerequisites, and stated preview rule caps. All of it, however, comes from one Google Cloud-authored post on dev.to with no independent testing, no third-party reproduction, and no upstream documentation in the cluster, so specificity substitutes for corroboration.
Preview availability, no usage evidence
Supplied material documents availability, not uptake: Public Preview status, a minimum GKE version, a Dataplane V2 requirement, preview rule caps, and a Cilium 1.19 backport with upstream availability promised in 1.20. There are no deployment counts, customer references, benchmarks, or usage disclosures, and the alpha API version plus preview limits argue against production commitment today.
Framing outruns the residual default
The headline promise is non-overridable, cluster-wide security boundaries, and the tier mechanics do deliver an Admin verdict developers cannot bypass. But the same source states unmatched traffic hits GKE's implicit allow and that Baseline default-deny is developer-overridable, so what is actually delivered is enumerated, first-match guardrails rather than a deny-by-default cluster. Combined with preview status, alpha API, per-object rule caps, and zero adoption evidence, the claim runs moderately ahead of the demonstrated posture — not wildly, since the source itself discloses the limits.
Vendor-authored feature promotion
The only source is a Google Cloud deep dive on its own preview feature, published to a developer community platform, framing the prior state of the art as fragile and difficult to audit and its own open-source alignment as a commitment to community-driven foundations. That is straightforward product advocacy; there is no adversarial review, competing implementation, or customer voice in the cluster to offset it.
Coherent mechanics, one publisher
Internal consistency is high and the technical detail is checkable, which supports moderate confidence in the described semantics. Confidence is held down by a one-publisher, one-article cluster with vendor incentives, preview-stage and alpha-API status, and no adoption or independent verification data, so any conclusion about real-world behaviour at scale remains provisional.
build
Identical Helm charts, three clouds, one OOMKill loop: portability is a claim about YAML1 distinct publisher
build
On GKE Autopilot, a NetworkPolicy blocks the API server and Postgres takes the blame1 distinct publisher
build
A NetworkPolicy in another repo broke invoicing while every dashboard reported success1 distinct publisher
build
Thirteen tasks green, then "give up (Recommended)" on the one that needed understanding1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026