Configuring Private Google Access for on-premises hosts

Private Google Access for on-premises enables your on-premises hosts to reach Google APIs and services through a Cloud VPN tunnel or Cloud Interconnect connection. Hosts don't need an external IP address.

GCP offers two VIP (virtual IP address) ranges for private connectivity: restricted.googleapis.com (199.36.153.4/30) and private.googleapis.com (199.36.153.8/30). We recommend that you use restricted.googleapis.com, which integrates with VPC Service Controls and mitigates data exfiltration risks by disallowing access to Google APIs and services that don't support VPC Service Controls. However, if you require access to other Google APIs and services that aren't supported by VPC Service Controls, use private.googleapis.com. In either case, Virtual Private Cloud service perimeters are always enforced.

For more information about each VIP range, refer to Domain names and VIPs.

Before you begin

  • You must enable the APIs that you want to access through the APIs & services page in the Google Cloud Platform Console.
  • Project owners, editors, and IAM members with the Network Admin role can create or update subnets and assign IP addresses. For more information on roles, read the IAM roles documentation.
  • Private Google Access requires a VPC network. Both auto and custom mode VPC networks are supported. Legacy networks are not supported.
  • For the route, firewall, and DNS configurations, choose whether to use the restricted.googleapis.com (199.36.153.4/30) or private.googleapis.com (199.36.153.8/30) domain name and VIP range. For more information, refer to Domain names and VIPs.
  • Your VPC network is already connected to your on-premises network by using a Cloud VPN tunnel or Cloud Interconnect connection.
  • Your VPC network must have a route for traffic destined to 199.36.153.4/30 or 199.36.153.8/30 (depending on the VIP you use) whose next hop is the default Internet gateway. You can do this by using the default route or a custom static route.

Setting up Private Google Access for on-premises hosts

To set up Private Google Access for on-premises hosts, you must complete the following tasks:

  • You must configure routes so that Google API traffic is forwarded through your Cloud VPN or Cloud Interconnect connection. For more information, see Configuring routes. If you have multiple tunnels or interconnects, you can't create cross-region asymmetric routes back to your on-premises network. GCP doesn't support them.
  • You must configure firewall rules on your on-premises firewall to allow traffic from your on-premises hosts to reach a particular VIP range. For more information, see Configuring firewall rules.
  • You must configure DNS so that traffic to Google APIs resolves to to correct domain name (restricted.googleapis.com or private.googleapis.com). For more information, see Configuring DNS.

Configuring routes

Cloud Router custom advertisements

You can use a Cloud Router custom route advertisement to announce the VIP_RANGE (199.36.153.4/30 or 199.36.153.8/30) to your on-premises network. Even though these are public IP address ranges, Google doesn't advertise routes to them publicly. These IP address ranges are only accessible to on-premises hosts that can reach your VPC network through internal IP addresses, such as through a Cloud VPN tunnel or Cloud Interconnect connection.

You can configure a custom route advertisement for all BGP sessions on the Cloud Router or a just select BGP session (for example, for a single Cloud VPN tunnel or VLAN attachment).

To create a custom route advertisement for a particular VIP range for all BGP sessions on an existing Cloud Router:

Console


  1. Go to the Cloud Router page in the Google Cloud Platform Console.
    Cloud Router list
  2. Select the Cloud Router to update.
  3. In the Cloud Router's detail page, select Edit.
  4. Expand the Advertised routes section.
  5. For the Routes, select Create custom routes.
  6. Select Advertise all subnets visible to the Cloud Router to continue advertising the subnets available to the Cloud Router. Enabling this option mimics the Cloud Router's default behavior.
  7. Select Add custom route to add an advertised route.
  8. Configure the route advertisement.
    • Source — Select Custom IP range to specify a custom IP range.
    • IP address range — Specify VIP_RANGE.
    • Description — Add a description for this advertisement.
  9. After you're done adding routes, select Save.

gcloud


Run the update command, using either the --set-advertisement-ranges or --add-advertisement-ranges flag to specify the custom IP ranges:

  • To set custom IP ranges, use the --set-advertisement-ranges flag. Any existing custom advertisements are replaced. The following example updates the my-router Cloud Router to advertise all subnets and the Google APIs IPs range VIP_RANGE:

    gcloud compute routers update my-router \
        --advertisement-mode CUSTOM \
        --set-advertisement-groups ALL_SUBNETS \
        --set-advertisement-ranges VIP_RANGE
    
  • To append custom IP ranges to an existing advertisement, use the --add-advertisement-ranges flag. Note that this flag requires the Cloud Router's advertisement mode to already be set to custom. The following example adds private.googleapis.com to the Cloud Router's advertisements:

    gcloud compute routers update my-router \
        --add-advertisement-ranges VIP_RANGE
    

To create a custom route advertisement for particular VIP range on a specific BGP session of an existing Cloud Router:

Console


  1. Go to the Cloud Router page in the Google Cloud Platform Console.
    Cloud Router list
  2. Select the Cloud Router that contains the BGP session to update.
  3. In the Cloud Router's detail page, select the BGP session to update.
  4. In the BGP session details page, select Edit.
  5. For the Routes, select Create custom routes.
  6. Select Advertise all subnets visible to the Cloud Router to continue advertising the subnets available to the Cloud Router. Enabling this option mimics the Cloud Router's default behavior.
  7. Select Add custom route to add an advertised route.
  8. Configure the route advertisement.
    • Source — Select Custom IP range to specify a custom IP range.
    • IP address range — Specify VIP_RANGE.
    • Description — Add a description for this advertisement.
  9. After you're done adding routes, select Save.

gcloud


Run the update-bgp-peer command, using either the --set-advertisement-ranges or --add-advertisement-ranges flag to specify the custom IP ranges.

  • To set custom IP ranges, use the --set-advertisement-ranges flag. Any existing custom advertisements are replaced. The following example updates the my-bgp-session BGP session on the my-router Cloud Router to advertise all subnets and the custom IP range VIP_RANGE:

    gcloud compute routers update-bgp-peer my-router \
        --peer-name my-bgp-session \
        --advertisement-mode CUSTOM \
        --set-advertisement-groups ALL_SUBNETS \
        --set-advertisement-ranges VIP_RANGE
    
  • To append custom IP ranges to existing ones, use the --add-advertisement-ranges flag. Note that this flag requires the Cloud Router's advertisement mode to already be set to custom. The following example adds VIP_RANGE to the Cloud Router's advertisements:

    gcloud compute routers update-bgp-peer my-router \
        --peer-name my-bgp-session \
        --add-advertisement-ranges VIP_RANGE
    

    For more information about custom advertisements, refer to Custom Router Advertisements.

VPC network route requirement

Your VPC network must have a route for traffic destined to a VIP range whose next hop is the default internet gateway. In a newly created VPC network, you can use the default route; however, you can also create a custom static route whose destination is the chosen VIP range and whose next hop is the default internet gateway. Creating a custom static route is required if you remove the default route.

Configuring firewall rules

You must configure your on-premises firewall rules to allow traffic from your on-premises hosts to reach the restricted or private VIP range.

Configuring DNS

Configure DNS to resolve *.googleapis.com as a CNAME to DOMAIN_NAME (either restricted.googleapis.com or private.googleapis.com), and create the appropriate A record for DOMAIN_NAME.

You can use either a Cloud DNS managed private zone with a Cloud DNS inbound forwarding policy, or you can configure a DNS name server in your on-premises network, such as BIND.

  • Cloud DNS private DNS zones enable you to host a DNS zone accessible from authorized VPC networks and, if you configure forwarding, from certain on-premises name servers. You can create a private zone for googleapis.com with an A record for DOMAIN_NAME and a CNAME record that directs *.googleapis.com to DOMAIN_NAME. Cloud DNS private zones do not support partial overrides, which means that you can only choose to redirect all requests to *.googleapis.com to DOMAIN_NAME. As a result, you won't be able to use any Google APIs and services that do not support use of your chosen domain name. For more information, see Managing Zones.
  • You can't use BIND and the restricted.googleapis.com or private.googleapis.com domain for Cloud Dataflow because DNS resolution of Cloud Dataflow can't be customized.

Configuring DNS with Cloud DNS

To enable DNS resolution for Private Google Access by using Cloud DNS, use the following procedure:

gcloud


  1. Create a managed private zone and authorize it to be used by your VPC network.

    gcloud dns managed-zones create apis \
        --visibility private \
        --networks https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/[NETWORK] \
        --dns-name googleapis.com \
        --description "Private Google APIs access"
    
  2. Create a policy and enable inbound forwarding for your VPC network.

    gcloud beta dns policies create apipolicy \
        --networks https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/[NETWORK] \
        --enable-inbound-forwarding \
        --description "enable inbound forwarding for Private Google APIs"
    
  3. Start a transaction.

    gcloud dns record-sets transaction start -z apis
    
  4. Add DNS records.

    gcloud dns record-sets transaction add --name=*.googleapis.com. \
        --type=CNAME DOMAIN_NAME. --zone apis --ttl 300
    
    gcloud dns record-sets transaction add --name=DOMAIN_NAME \
        --type=A IP_ADDRESS_1 IP_ADDRESS_2 IP_ADDRESS_3 IP_ADDRESS_4\
        --zone apis --ttl 300
    

    The following example creates a DNS record for the private.googleapis.com domain:

    gcloud dns record-sets transaction add --name=private.googleapis.com. \
        --type=A 199.36.153.8 199.36.153.9 199.36.153.10 199.36.153.11 \
        --zone apis --ttl 300
    
  5. Execute the transaction.

    gcloud dns record-sets transaction execute --zone apis
    
  6. In your on-premises network, point your on-premises DNS to the Cloud DNS forwarder IP address. To find the forwarder IP address, use the compute addresses list command:

    gcloud compute addresses list --filter='name ~ ^dns-forwarding.*' \
        --format='csv[no-heading](address, subnetwork)'
    

Configuring DNS with BIND

If you use BIND for your on-premises DNS resolution, you can configure it to redirect requests for *.googleapis.com to a particular domain name by using response policy zones (RPZ), as shown in the following BIND configuration:

  1. Add the following lines to /etc/bind/named.conf:

    include "/etc/bind/named.conf.options";
    include "/etc/bind/named.conf.local";
    
  2. Add the following lines to /etc/bind/named.conf.options:

    options {
      directory "/var/cache/bind";
    
      dnssec-validation no;
    
      auth-nxdomain no;    # conform to RFC 1035
      listen-on-v6 { any; };
      listen-on { any; };
      response-policy { zone "googleapis.zone"; };
      allow-query { any;};
    };
    
  3. Add the following lines to /etc/bind/named.conf.local:

    include "/etc/bind/named.conf.default-zones";
    
    zone "googleapis.zone" {
      type master;
      file "/etc/bind/db.googleapis.zone";
      allow-query {none;};
    };
    
  4. Add the following lines to /etc/bind/db.googleapis.zone:

    $TTL 1H
    @                       SOA LOCALHOST. noreply.localhost(1 1h 15m 30d 2h)
                            NS  LOCALHOST.
    
    *.googleapis.com CNAME DOMAIN_NAME.
    DOMAIN_NAME CNAME rpz-passthru.
    

What's next

Was this page helpful? Let us know how we did:

Send feedback about...