GKE clusters still on routes-based networking instead of alias IPs
What does ZopNight detect here?
Routes-based GKE clusters cannot enforce NetworkPolicy, use pod-range firewall rules, or adopt most newer GKE networking features. ZopNight rule RC-1224 fires on the discoverer's explicit alias_ips=false signal and abstains when the field is absent. Remediation is a migration. VPC-native networking cannot be switched on in place, so a new cluster is required.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1224 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | gke_alias_ips.go |
Where it applies
No toggle exists for this one
Start with the uncomfortable part: a routes-based GKE cluster cannot be converted to VPC-native in place. There is no flag to flip and no upgrade path. Remediation means standing up a new cluster created with --enable-ip-alias, migrating workloads, and repointing DNS and load balancers. That makes this finding a planning item, not a ticket someone closes in an afternoon, and it is why the findings you see are almost always clusters old enough to predate VPC-native becoming the default for new clusters.
What routes-based clusters give up
In a routes-based cluster, pod IPs ride on custom VPC routes rather than being first-class alias IP ranges on the subnet. The practical ceiling: NetworkPolicy enforcement is unavailable, firewall rules cannot target pod ranges, private Google access for pods is off the table, and each cluster consumes routes from a per-network quota that caps how many clusters and nodes a VPC can hold. Several adjacent compliance findings, network policy among them, are literally unfixable until this one is resolved, which is a reason to sequence it early despite the migration cost.
Detection and its limits
Rule RC-1224 reads the alias_ips value the discoverer emits, preferring the authoritative metadata sink and falling back to the tags mirror when metadata is absent. Only an explicit false fires; an absent or empty value abstains, so an unobserved cluster is never flagged. The rule sees only the networking mode, not how disruptive migration would be for the workloads inside.
Verify a cluster’s mode
gcloud container clusters describe my-cluster --location us-central1 \ --format='value(ipAllocationPolicy.useIpAliases)'Anything other than True means routes-based.
Sequencing the migration
Treat the new cluster as a chance to bank every recreate-only fix at once: private nodes, network policy, and VPC-native all land in the same rebuild, so one migration window pays down three findings. Plan subnet secondary ranges for pods and services before creating the cluster; undersized ranges are the classic VPC-native regret, and resizing them later is its own project.