You can use VPC Service Controls to control access to Google APIs and services from hosts that use private IP addresses. These hosts can be VM instances in a VPC network or clients in an on-premises network.
To restrict Private Google Access within a service perimeter to only
VPC Service Controls supported Google APIs and services,
hosts must send their requests to the restricted.googleapis.com
domain name
instead of *.googleapis.com
. The restricted.googleapis.com
domain resolves
to a VIP (virtual IP address) range 199.36.153.4/30
. This IP address range is
not announced to the Internet.
The following sections describe how to set up private connectivity for hosts in a VPC network or on-premises network. For an overview and example topology diagrams, refer to Private Google Access with VPC Service Controls.
Before you begin
- You must enable the APIs that you want to access through the APIs & services page in the Google Cloud 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 and Private Google Access for on-premises hosts requires a VPC network. Both auto and custom mode VPC networks are supported. Legacy networks are not supported.
- For VM instances in a VPC network, they must have a private IP address only (no public IP address) and be in subnet with Private Google Access enabled.
- For on-premises hosts, you must have an existing Cloud VPN tunnel or an Cloud Interconnect connection to your VPC network.
Overview of procedure
To set up private connectivity, complete the following tasks:
- Configure routes for the destination
199.36.153.4/30
. For more information, see Configuring routes. - Configure firewall rules to allow the appropriate traffic to the restricted Google APIs IP address range. For more information, see Configuring firewall rules.
- Configure DNS so that traffic to Google APIs resolves to the Restricted Google APIs IP address range. For more information, see Configuring DNS.
Configure a route to restricted.googleapis.com
For both Private Google Access and Private Google Access for on-premises
hosts, your VPC network must include a route for with a
destination to 199.36.153.4/30
whose next hop is the default Internet gateway.
Even though the next hop is a default Internet gateway, traffic sent to
199.36.153.4/30
remains within Google's network. Your VPC
network might already have a default
route whose next hop is the default
Internet gateway. If not, you can create a custom static route whose destination
is 199.36.153.4/30
and whose next hop is the default Internet gateway.
In addition to the custom static route, Private Google Access for on-premises hosts requires a custom route advertisement so that hosts in the on-premises network can learn about the restricted VIP. You can create a custom dynamic route using Cloud Router to announce the restricted VIP.
For more information about working with VPC routes, see Using Routes in the VPC documentation.
Configuring a custom static route in a VPC network
Add a custom static route to enable access to Google managed services that are supported by VPC Service Controls.
Add a custom route that allows access only to Google managed services secured by VPC Service Controls.
gcloud compute routes create ROUTE_NAME \ --network=NETWORK_NAME \ --destination-range=199.36.153.4/30 \ --next-hop-gateway=default-internet-gateway
Replace the following:
ROUTE_NAME
: a name for the custom route.NETWORK_NAME
: the name of your VPC network.
Announcing the restricted route to hosts in an on-premises network
If you're using Private Google Access for on-premises hosts, configure routes
so that Google API traffic is forwarded through your Cloud VPN or
Cloud Interconnect connection. To announce the restricted VIP
(199.36.153.4/30
) to your on-premises network, use Cloud Router Custom
Route Advertisement.
This IP address range is only accessible to on-premises hosts that can reach
your VPC network through private IP addresses.
You can add this custom route advertisement to a Cloud Router (for all BGP sessions on the router) or a select BGP session (for a single Cloud VPN tunnel or VLAN attachment).
To create a custom route advertisement for the restricted range for all BGP sessions on an existing Cloud Router:
Console
- Go to the Cloud Router page in the Google Cloud Console.
Cloud Router list - Select the Cloud Router to update.
- In the Cloud Router's detail page, select Edit.
- Expand the Advertised routes section.
- For the Routes, select Create custom routes.
- 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.
- Select Add custom route to add an advertised route.
- Configure the route advertisement.
- Source — Select Custom IP range to specify a custom IP range.
- IP address range — Specify
199.36.153.4/30
. - Description — Add a description of
Restricted Google APIs IPs
.
- 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 themy-router
Cloud Router to advertise all subnets and the Restricted Google APIs IPs range199.36.153.4/30
:gcloud compute routers update my-router \ --advertisement-mode CUSTOM \ --set-advertisement-groups ALL_SUBNETS \ --set-advertisement-ranges 199.36.153.4/30
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 tocustom
. The following example adds theRestricted Google APIs IPs
custom IP to the Cloud Router's advertisements:gcloud compute routers update my-router \ --add-advertisement-ranges 199.36.153.4/30
To create a custom route advertisement for the restricted range on a specific BGP session of an existing Cloud Router:
Console
- Go to the Cloud Router page in the Google Cloud Console.
Cloud Router list - Select the Cloud Router that contains the BGP session to update.
- In the Cloud Router's detail page, select the BGP session to update.
- In the BGP session details page, select Edit.
- For the Routes, select Create custom routes.
- 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.
- Select Add custom route to add an advertised route.
- Configure the route advertisement.
- Source — Select Custom IP range to specify a custom IP range.
- IP address range — Specify
199.36.153.4/30
. - Description — Add a description of
Restricted Google APIs IPs
.
- 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 themy-bgp-session
BGP session on themy-router
Cloud Router to advertise all subnets and the custom IP range199.36.153.4/30
:gcloud compute routers update-bgp-peer my-router \ --peer-name my-bgp-session \ --advertisement-mode CUSTOM \ --set-advertisement-groups ALL_SUBNETS \ --set-advertisement-ranges 199.36.153.4/30
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 tocustom
. The following example adds the199.36.153.4/30
Restricted Google APIs IPs to the Cloud Router's advertisements:gcloud compute routers update-bgp-peer my-router \ --peer-name my-bgp-session \ --add-advertisement-ranges 199.36.153.4/30
For more information about custom advertisements, refer to Custom Router Advertisements.
Configure firewall rules
For Private Google Access, VM instances use internal IP addresses and don't require external IP addresses to reach protected Google API resources. However, it's possible for VM instances to possess external IP addresses or otherwise meet the requirements for Internet access. In addition to custom routes, you can restrict egress traffic from VM instances in your VPC network by creating firewall rules to deny egress traffic.
By default, the implied allow egress firewall
rule permits VM instances to send
traffic to any destination if an applicable route exists. You can create an
egress deny rule to block all outbound traffic, and then create higher
priority egress allow rules to permit traffic to selected destinations in your
VPC network and to the 199.36.153.4/30
(restricted.googleapis.com
) IP address range. All communication to
restricted.googleapis.com
is on TCP port 443
.
For more information about working with VPC firewall rules, see Using Firewall Rules in the VPC documentation.
Firewall rules in on-premises networks
You must configure your on-premises firewall rules to allow traffic from your
on-premises hosts to reach 199.36.153.4/30
.
Configuring DNS
For general use of VPC Service Controls, we recommend that you use
Cloud DNS response policies
to configure DNS for your VPC networks. This lets you configure
DNS without having to create a managed private zone.
A response policy uses passthru
behavior to let names, such as
www.googleapis.com
, be allowed past the wildcard name in the
example *.googleapis.com
. For more information, see Managing response
policies and rules.
You can also use managed private zones for your VPC networks.
Cloud DNS private DNS zones enable you to host a DNS zone accessible from
authorized VPC networks.
To make use of the Restricted Google APIs IP addresses, if you configure
forwarding from certain on-premises name servers, you can create a private
zone for googleapis.com
with an A record for restricted.googleapis.com
and
appropriate CNAME records for each *.googleapis.com
name. For more
information, see Managing zones.
For on-premises access, you can configure a Cloud DNS inbound forwarding policy to enable on-premises name servers to query a Cloud DNS managed private zone, or you can configure an on-premises name server, such as one using BIND:
Configuring DNS with Cloud DNS
Use Cloud DNS to enable DNS resolution for VM instances in your VPC network, hosts in an on-premises network, or both. If you're using Shared VPC, see Private zones and Shared VPC in the Cloud DNS documentation. Additionally, if you're using Shared VPC, ensure that the Shared VPC network host project is included in the same service perimeter as projects that connect to the network.
You can configure DNS with Cloud DNS by using response policies or private zones.
Using response policies to configure Cloud DNS
Directing specific names to restricted VIP addresses
You can configure a response policy that has local CNAME data for each zone to translate Google API requests to restricted Google APIs. Names that aren't specified continue to be resolved by using regular DNS.
For example, you can create a response policy for pubsub.googleapis.com
,
which has local CNAME data for a zone, to translate Google API requests to
restricted.googleapis.com
. In the meantime, www.googleapis.com
, which is
unspecified, continues to be resolved by using regular DNS.
In the following example configuration, you create a policy and apply it to a specific VPC network.
Create a response policy by URL:
{ kind: "dns#responsePolicy", response_policy_name: RESPONSE_POLICY_NAME, description: RESPONSE_POLICY_DESCRIPTION, networks: [ { network_url: URL_TO_NETWORK; } ] }
Replace the following:
RESPONSE_POLICY_NAME
: a name for the response policyRESPONSE_POLICY_DESCRIPTION
: a description of the response policyURL_TO_NETWORK
: the URL for which you're creating the response policy
Add a rule to the policy:
{ kind: "dns#responsePolicyRules", rule_name: RULE_NAME, dns_name: DNS_NAME, local_data: [ { name: "pubsub.googleapis.com.", type: "A", ttl: 300, rrdata: ["199.36.153.4", "199.36.153.5", "199.36.153.6", "199.36.153.7"] } ] }
Replace the following:
RULE_NAME
: a name for the rule that you are creating, such aspubsub
DNS_NAME
: the DNS name for which you are creating the rule, such aspubsub.googleapis.com.
; note the trailing dot
Directing all names except some to restricted VIP addresses
You can set rules to exempt some DNS responses from a policy rule that covers an entire domain or a large IP address block. This concept is called passthru behavior. By using passthru behavior, you can let names that lack support for service controls be allowed past the wildcard name.
For example, you can let www.googleapis.com
be allowed past the
wildcard name in the example *.googleapis.com
. The exact match for www
takes precedence over the wildcard *
.
In the following example configuration, you create a policy with a specified name
and apply it to a specific VPC network. The rule allows
www.googleapis.com
to bypass the wildcard *.googleapis.com
.
Create a response policy:
{ kind: "dns#responsePolicy", response_policy_name: RESPONSE_POLICY_NAME, description: RESPONSE_POLICY_DESCRIPTION, networks: [ { network_url: URL_TO_NETWORK; } ] }
Replace the following:
RESPONSE_POLICY_NAME
: a name for the response policy, such asmy-response-policy
RESPONSE_POLICY_DESCRIPTION
: a description of the response policy, such asmy response policy
URL_TO_NETWORK
: the URL for which you're creating the response policy
Add a rule to the policy:
{ kind: "dns#responsePolicyRules", rule_name: RULE_NAME, dns_name: DNS_NAME, local_data: [ { name: "*.googleapis.com.", type: "A", ttl: 300, rrdata: ["restricted.googleapis.com."] } ] } { kind: "dns#responsePolicyRules", rule_name: "www-passthru", dns_name: "www.googleapis.com.", behavior: BYPASS_RESPONSE_POLICY }
Replace the following:
RULE_NAME
: a name for the rule that you are creating, such asgoogleapis
DNS_NAME
: the wildcard DNS name for which you are creating the rule, such as*.googleapis.com.
; note the trailing dot
Using private zones to configure Cloud DNS
Use private zones to configure Cloud DNS when you cannot use response policies.
Create a managed private zone for your VPC network.
gcloud beta dns managed-zones create ZONE_NAME \ --visibility=private \ --networks=https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK_NAME \ --description=DESCRIPTION \ --dns-name=googleapis.com
Replace the following:
ZONE_NAME
: a name for the zone that you are creating. For example,vpc
. This name will be used in each of the following steps.PROJECT_ID
: the ID of the project that hosts your VPC network.NETWORK_NAME
: the name of your VPC network.DESCRIPTION
: an optional, human-readable description of the managed zone.
Start a transaction.
gcloud dns record-sets transaction start --zone=ZONE_NAME
Replace
ZONE_NAME
with the name of the zone that you created in the first step.Add DNS records.
gcloud dns record-sets transaction add --name=*.googleapis.com. \ --type=CNAME restricted.googleapis.com. \ --zone=ZONE_NAME \ --ttl=300
Replace
ZONE_NAME
with the name of the zone that you created in the first step.gcloud dns record-sets transaction add --name=restricted.googleapis.com. \ --type=A 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 \ --zone=ZONE_NAME \ --ttl=300
Replace
ZONE_NAME
with the name of the zone that you created in the first step.Execute the transaction.
gcloud dns record-sets transaction execute --zone=ZONE_NAME
Replace
ZONE_NAME
with the name of the zone that you created in the first step.Optional. To enable on-premises hosts to reach the restricted VIP, complete the following steps:
Create a DNS policy and enable inbound DNS forwarding to make VPC network's name resolution services externally available to systems in on-premises networks,
gcloud beta dns policies create POLICY_NAME \ --networks=https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK_NAME \ --enable-inbound-forwarding \ --description=DESCRIPTION
Replace the following:
POLICY_NAME
: a name for the policy that you are creating. For example,apipolicy
.PROJECT_ID
: the ID of the project that hosts your VPC network.NETWORK_NAME
: the name of your VPC network.DESCRIPTION
: an optional, human-readable description of the managed zone.
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 DNS resolution, you can configure it to resolve Google API requests to the restricted Google APIs. Use the following example BIND configuration, which makes use of response policy zones (RPZ) to achieve this behavior:
Add the following lines to
/etc/bind/named.conf
:include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local";
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;}; };
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;}; };
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 restricted.googleapis.com. restricted.googleapis.com CNAME rpz-passthru.
Configuring DNS in special cases
When you need to configure DNS in special cases, keep the following in mind:
- Custom BIND is not supported when using Dataflow. To customize DNS resolution when using Dataflow with VPC Service Controls, use Cloud DNS private zones instead of using custom BIND servers. To use your own on-premises DNS resolution, consider using a Google Cloud DNS forwarding method.
You might need to also configure DNS for
gcr.io
if, for example, you're using Google Kubernetes Engine (GKE). For more information, refer to Setting up Container Registry for GKE private clusters.