Network Services and Connectivity in GCP — API Access

It’s only when you work on Google Cloud Platform (GCP) for a while that you come across the many different network connectivity options and services that exist within GCP. The names of some of these features are at times confusing and eerily similar, making it hard to understand their functionality or purpose.

This series of articles will try to address the most common network services that you may come across and provide some details on the functionality that they provide. I will use variations of the following diagram to demonstrate all of these features, so you have a similar context to understand these features.

Disclaimer: I have little understanding of the internal architecture of GCP networking and do not claim that the ideas presented here are accurate in terms of the internal designs of GCP networking. The information here is based on my interactions and research with various network configurations in GCP and deduced from information found in Google network documentation.

Base diagram showing environments that interact with GCP

This is a Google centric view of all external and internal environments that we are discussing in these articles to demonstrate the network services in GCP.

• Google Software defined network: This is a representation of all things networking inside the Google Cloud platform, including the customer GCP environments and VPCs, and Google’s own infrastructure that hosts the APIs and services provided by Google. The public and private endpoints listed are just to identify the IP address ranges that they can be reached at — it is not to indicate that one is externally accessible from the Internet and the other is not.
• Public Internet: Indication that the traffic flowing through that box in the following explanations are through the open public internet.
• Customer On-premises: A data center or co-located facility — or even another Cloud provider — where the customer hosts their own workloads, or an office facility where the employees work from.
• Google Partner Infrastructure: These may be separate locations or data centers from which direct physical connectivity exists to Google environments, and Google technology partners host managed services like Bare metal servers, Google Cloud VMware engine or Netapp managed storage.
• Customer Internet Services Partner: This may be a co-located facility that integrates or provides Internet and private WAN connectivity to a customer. These service providers typically have partnership and cross connectivity into Google data centers or meet them at co-located facilities to provide private Layer 2 and Layer 3 based high bandwidth access in to GCP.

So let’s dive in..

Private Google Access

All access to Google APIs from the public internet, back office networks or on-prem data centers use the public API endpoints for GCP by default. These are the addresses that *.googleapis.com resolves on the Internet. This is true also for API access from any Compute instances attached to your Google VPC, by default. However for access to public endpoints from a Google VPC, you need to either have a public address on the compute instance or Cloud NAT configured in the region that the instance belongs in . This is because the instance will need access to the internet to reach to these public endpoints.

Private Google Access allows compute instances in a VPC to reach the Google APIs using internal Google networks without Cloud NAT. This feature can be turned on a per subnet basis in the Google VPC network configuration.

This diagram shows the difference between public and private Google API access.

Public vs Private API Access from a Google VPC

Restricted API Access

Restricted API access allows controlled access to Google APIs using DNS and custom routing from a Google VPC, or customer On-premise environments. Restricted API access for all Google APIs are published at the public IPv4 IP address range 199.36.153.4/30.

The following steps are used to implement this:

• Set up a private DNS zone for googleapis.com in an on-premise DNS server.
• Set up a CNAME record for *.googleapis.com in that zone, that directs to restricted.googleapis.com
• Provide the four addresses in the above address range as A records for restricted.googleapis.com in the private DNS zone.
• Set up a route for the above address range to the destination that directs traffic to a Google VPC, for example an Interconnect or VPN tunnel.

The traffic originating from any networks that the private DNS domain is accessible from, will now send the Google APIs traffic through the designated Interconnect or VPN tunnel. This may be used for compliance reasons, traffic monitoring or perimeter control. Combining Restricted API access with VPC service control policies is a powerful way to control where your GCP environment can be accessed from.

Some customers direct all their outbound HTTPS access from a VPC through an outbound proxy for URL filtering. The above DNS + routing configuration can be used in a Google VPC to bypass Google API traffic from such proxies. In this case, a Cloud DNS private zone will be created as mentioned above in the network project and attached to the VPC, and a specific route will direct the Restricted API range to the default internet gateway, while all HTTPS traffic is sent to the outbound proxy via a default route of 0.0.0.0/0.

Following diagram shows the Restricted API access in detail.

Controlled Google API access through Restricted API routing

These above scenarios show how access to Google APIs from within a VPC or from an on-premise environment can be controlled using Google network features for API access.

We will review the network services that provide traffic controls between Google VPCs and Google or third party Managed services in Part 2.