# GKE Cluster Alias IPs Not Enabled

> 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.

Source: https://zop.dev/integrations/gcp/recommendations/gke-cluster-alias-ips-not-enabled
Updated: 2026-08-19

---

## 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

```bash
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.