Skip to main content

More Info:

Use VPC-native clusters (alias IP) so pod and service IPs are native VPC addresses, enabling better network integration and firewalling. Route-based clusters are less secure and scalable.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify whether the cluster is VPC‑native and document current state
    • On any machine with gcloud and project access, run:
    • Confirm whether .useIpAliases is true. If it is true, this control is satisfied for this cluster; record that result. If false or null, proceed.
  2. Assess business/technical requirements and compatibility for migration
    • Review whether any workloads rely on node IPs or legacy routing (e.g., custom routes, firewalls keyed to node IPs, non‑GCP VPN/peering relying on current pod CIDRs).
    • Document required CIDR ranges for pods/services and overlap risks with existing VPCs, VPNs, and peered networks.
  3. Design a VPC‑native cluster configuration
    • On a planning workstation, draft the target settings (example):
    • Ensure these ranges do not overlap with any existing on‑prem, VPC, or peered CIDRs.
    • Decide whether you will recreate the cluster manually, via scripts, or via IaC (Terraform, Deployment Manager, etc.), and record that as the approved migration plan.
  4. Create a new VPC‑native (Alias IP) cluster according to your plan
    • When ready to migrate, create a replacement cluster with Alias IP enabled (on any machine with gcloud):
    • If you use IaC, encode equivalent settings there instead of running the CLI directly, and have them reviewed/approved.
  5. Migrate workloads and traffic to the VPC‑native cluster
    • Point kubectl to the new cluster:
    • Recreate namespaces, RBAC, ConfigMaps, Secrets, Deployments, Services, Ingress, and other resources from source control or exported manifests.
    • Update DNS, load balancer configs, and any external dependencies to direct traffic to the new cluster’s endpoints. Perform validation tests before decommissioning the old cluster.
  6. Verify and formally close the finding
    • On any machine with gcloud, confirm the new cluster is VPC‑native:
    • Ensure it returns true.
    • Once the old (route‑based) cluster is no longer needed, delete it:
    • Update your documentation and risk register to reflect that all active clusters are now VPC‑native.
This setting is part of the GKE control plane / cluster configuration and cannot be changed with kubectl, which only manages Kubernetes API objects. To address this finding, use the Google Cloud console, gcloud CLI, or your IaC as described in the Manual Steps section.
How to useRun on any machine with gcloud and jq:
Interpreting results
  • useIpAliases=true → cluster is VPC-native (Alias IP) and aligned with the control.
  • useIpAliases=false → cluster is not VPC-native and is a finding to review.
  • unknown or error → unable to determine; investigate that cluster manually with: