Google CloudOverview
Private Google Access enables your cluster hosts, which have only private IP addresses, to communicate with Google APIs and services using an internal IP address rather than an external IP address. External IP addresses are routable and reachable over the Internet. Internal (private) IP addresses are internal to Google Cloud Platform and are not routable or reachable over the Internet. You can use Private Google Access to allow VMs without Internet access to reach Google APIs, services, and properties that are accessible over HTTP/HTTPS.
Rationale
VPC networks and subnetworks provide logically isolated and secure network partitions where you can launch GCP resources. When Private Google Access is enabled, VM instances in a subnet can reach the Google Cloud and Developer APIs and services without needing an external IP address. Instead, VMs can use their internal IP addresses to access Google managed services. Instances with external IP addresses are not affected when you enable the ability to access Google services from internal IP addresses. These instances can still connect to Google APIs and managed services.
Remediation guidance
Using Console
- Go to Kubernetes GCP Console visiting https://console.cloud.google.com/kubernetes/list
- From the list of clusters, for each clusters note the
Subnetname - Go to VPC network GCP Console visiting https://console.cloud.google.com/networking/networks/list
- Click noted subnet, The
Subnet detailspage is displayed - Click on Edit button
- Set
Private Google accesstoOn - Click on Save
Using Command Line
To set Private Google access for a network subnet, run the following command:
gcloud compute networks subnets update \[SUBNET_NAME\] --region \[REGION\] --enable-private-ip-google-access
Impact
Instances with external IP addresses are not affected when you enable the ability to access Google services from internal IP addresses. These instances can still connect to Google APIs and managed services.
Default Value
By default, Private Google access is set to Off when you create a new cluster/cluster subnetwork.
References
- https://cloud.google.com/vpc/docs/configure-private-google-access
- https://cloud.google.com/vpc/docs/private-google-access
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Private Google Access is set on Kubernetes Engine Cluster Subnets
Connectors
Covered asset types
Expected check: eq []
gkeClusters(where:{subnetworks_SOME:{privateIpGoogleAccess:false}}){...AssetFragment}
