Overview
Google Cloud Platform Alias IP Ranges lets you assign ranges of internal IP addresses as aliases to a virtual machine's network interfaces. This is useful if you have multiple services running on a VM and you want to assign each service a different IP address.
Rationale
With Alias IPs ranges enabled, Kubernetes Engine clusters can allocate IP addresses from a CIDR block known to Google Cloud Platform. This makes your cluster more scalable and allows your cluster to better interact with other GCP products and entities. Using Alias IPs has several benefits:
- Pod IPs are reserved within the network ahead of time, which prevents conflict with other compute resources.
- The networking layer can perform anti-spoofing checks to ensure that egress traffic is not sent with arbitrary source IPs.
- Firewall controls for Pods can be applied separately from their nodes.
- Alias IPs allow Pods to directly access hosted services without using a NAT gateway.
Remediation guidance
Using Console
- Go to Kubernetes GCP Console by visiting https://console.cloud.google.com/kubernetes/list?
- Click on
CREATE CLUSTER - Choose required name/value for cluster fields
- Click on
More - Set
VPC native (using alias IP)toEnabled - Click on
Create
Using Command Line
To create a new cluster with Alias IP enabled, run the following command:
gcloud container clusters create \[CLUSTER_NAME\] --zone \[COMPUTE_ZONE\] --enable-ip-alias
Impact
You cannot migrate an existing routes-based cluster to Alias IPs in place. Create a new VPC-native cluster and migrate workloads. Cluster IPs for internal Services remain only available from within the cluster. If you want to access a Kubernetes Service from within the VPC, but from outside of the cluster, use an internal load balancer.
Default Value
By default, VPC native (using alias IP) is enabled when you create a new cluster.
References
- https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips
- https://cloud.google.com/vpc/docs/alias-ip
Service-wide remediation
Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.
Google Cloud
Use organization or folder policies where available, shared project templates, logs and alerting baselines, and IaC modules so new resources inherit the secure setting.
Operational rollout
- Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
- Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
- Re-scan and track approved exceptions with an owner and expiry date.
Query logic
These are the stored checks tied to this control.
Kubernetes Cluster is created with Alias IP ranges enabled
Connectors
Covered asset types
Expected check: eq []
gkeClusters(where:{ipAllocationPolicy_SOME:{useIPAliases:false}}){...AssetFragment}
Google Cloud