GETTING STARTED WITH PRIVATE GOOGLE ACCESS
PRIVATE GOOGLE ACCESS
PRIVATE GOOGLE ACCESS FOR ON-PREM HOSTS
OTHER TYPES OF PRIVATE ACCESS
The course is part of these learning paths
In this course, we look at configuring Private Google access starting with an overview of what it is, before moving on to networking and DNS configuration as well as routing and firewalls. We'll then walk you through a guided demonstration of how to enable Private Google Access so that you get a practical understanding of the service.
We'll also look at Private Google Access for on-premises hosts, covering domain names, virtual IPs, networking and DNS configuration, and permissions. We'll wrap with Private Services Access and Serverless VPC Access.
- Learn about Private Google Access, its networking and DNS requirements, and how to configure routing and firewalls to use it
- Learn about Private Google Access for on-premises hosts, its requirements, its permissions, and how to use it
- Get a high-level overview of Private Services Access and Serverless VPC Access
This course is intended for those who wish to learn how to configure private Google access on the GCP platform.
To get the most out of this course, you should have a basic knowledge of GCP.
Hello and welcome to private Google access. In this lesson, we will take an overview look at what private Google access is, along with the supported services, and an example implementation of private Google access.
Organizations will often use private Google access when they need to allow VM instances with no external IP addresses to reach the external IP addresses of Google APIs and services. When using private Google access to reach the external IP of a Google API or service, the source IP address can be either a primary internal IP address of a network interface, or it can be an IP address that’s part of an alias IP range that’s assigned to an interface. Without private Google access, VM’s with only internal IP addresses can only send traffic within the VPC network.
Since instances with external IP addresses can already access the internet, private Google access will have no effect on those instances.
I should mention that private Google access is enabled on a subnet by subnet basis and supports most Google cloud services except for App Engine Memcache, Filestore, and Memorystore.
The image that you see on your screen shows what a typical implementation of private Google access might look like.
In this example, egress firewall rules for the VPC network itself would typically be configured to allow access to 0.0.0.0/0. The A1 virtual machine in this example is able to access Google APIs and services, despite having only an internal IP address, because private Google access is turned on for subnet-a, which is the subnet that the A1 VM is attached to. Private Google access doesn’t apply to the A2 virtual machine because the A2 virtual machine has a public IP associated with it. Remember, private Google access has no effect on instances with public IPs.
Now, with that being said, the A2 virtual machine can still access Google APIs and services because it has that public IP.
As far as the instances on subnet-b go, the B1 virtual machine cannot access Google APIs and services because as you can see here, not only does B1 not have a public IP, but private Google access is turned off for subnet-b, which is the subnet that B1 is attached to. The B2 virtual machine, like A2, can in fact access Google APIs and services because of the public IP assigned to the instance.
Because private Google access can be enabled on a subnet by subnet basis, you can enable it during the creation of a subnet, or you can enable it for subnet after the subnet has been created. Assuming a VPC network meets the network requirements for Google APIs and services, once you enable private Google access for subnet on that VPC network, Google cloud will allow any virtual machines that are attached to that subnet to send traffic to the external IP addresses of Google APIs and services.
More specifically, traffic to Google APIs and services is allowed from the primary internal IP address of a virtual machine’s network interface, as long as it’s attached to a subnet enabled for private google access AND as long as it doesn’t have an external IP address assigned to it. Traffic to Google APIs and services is also allowed from an internal IP address that is part of an alias IP range of a virtual machine’s network interface that’s attached to a subnet that’s been enabled for private google access.
Now, I should point out that there are several network requirements that need to be met in order to leverage private Google access. For example, legacy networks are not supported by private Google access because they do not support subnets. Since private Google access is enabled on a per subnet basis, this is obviously a problem. So, for private Google access, you need to use VPC networks.
I should also mention that enabling private Google access doesn’t automatically enable any APIs. The APIs that you want to use need to be separately enabled through the APIs and services page in the Google cloud console.
It’s also important to keep in mind that if you plan to use the private.googleapis.com or restricted.googleapis.com domain names to access APIs, you’re going to have to create DNS records that resolve those domain names to the IP addresses of the APIs you are trying to access. In addition, you need to ensure that routes defined in your network, allow traffic to reach the destination IP ranges that are used by Google APIs and services. Essentially, this means that your defined routes must be configured with the default Internet gateway as the next hop.
And lastly, and this is pretty much a no-brainer, any defined egress firewalls must allow traffic to the IP ranges for Google APIs and services. The implied allowed egress firewall rule that Google cloud sets up automatically is sufficient to allow this traffic.
Join me in the next lesson, where we will dive into a more detailed discussion of networking and DNS configuration requirements.
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.