Course Introduction
GETTING STARTED WITH PRIVATE GOOGLE ACCESS
PRIVATE GOOGLE ACCESS
PRIVATE GOOGLE ACCESS FOR ON-PREM HOSTS
OTHER TYPES OF PRIVATE ACCESS
Course Conclusion
The course is part of these learning paths
See 2 moreIn 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.
Learning Objectives
- 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
Intended Audience
This Course is intended for those who wish to learn how to configure private Google access on the GCP platform.
Prerequisites
To get the most out of this Course, you should have a basic knowledge of GCP.
Welcome back! In this lesson, we are going to take a look at basic network configuration and DNS configuration that needs to be performed to support Private Google Access.
The table on your screen shows each of the Private Google Access domains along with their virtual IP ranges. It also shows which services are supported by each domain, along with common usage examples. To enable private google access, you must first decide which domain you wish to access Google APIs and services on.
You can see here that we have an entry for a few different domain options. We have default domains, the private.googleapis.com domain, and the restricted.googleapis.com domain.
The default domains refer to all domain names, except for private and restricted, that are used for Google APIs and services. These default domains consist of various IP address ranges and they provide access to most Google APIs and services whose names end with googleapis.com. Default domains are used if you don’t configure DNS records for private.googleapis.com and restricted.googleapis.com.
The private.googleapis.com domain has an IP range of 199.36.153.8/30. This domain is used to access Google APIs and Services via a set of IP addresses that are only routable from within Google Cloud. As you can see in this table, you would typically use private.googleapis.com in cases where you don’t use VPC Service Controls at all, OR when you DO use VPC Service Controls but also need to access Google APIs and Services that aren’t supported by them. Notice the long list of supported services.
Lastly, we have the restricted.googleapis.com domain, with a range of 199.36.153.4/30. This domain enables access to all Google APIs and services that are supported by VPC Service Controls and BLOCKS access to those that are not supported. You would use restricted.googleapis.com to access Google APIs and Services via a set of IPs that are only routable from within Google Cloud and when you need to access only those Google APIs and services that are supported by VPC Service Controls.
For more information on VPC Service Controls, visit the URL that you see on your screen:
https://cloud.google.com/vpc-service-controls/docs/private-connectivity
The domain you choose will determine how you need to configure DNS. More often than not, you’ll be using either private.googleapis.com or restricted.googleapis.com when leveraging Private Google Access. In these cases, what you need to do is configure your DNS so that your virtual machines in your VPC network can resolve *.googleapis.com.
To ensure your VMs can resolve *.googleapis.com, you need to create a private googleapis.com DNS zone. You can do this in your own DNS, or you can use Cloud DNS.
Once you have your googleapis.com zone created, you’ll need to one of two things.
If you plan to use private.googleapis.com to access Google APIs and services, you’ll create an A record for private.googleapis.com and you’ll point that record to the IP addresses you see on your screen:
- 199.36.153.8
- 199.36.153.9
- 199.36.153.10
- 199.36.153.11
If you plan to use restricted.googleapis.com instead, you’d create an A record and point it at the IPs you see on your screen:
- 199.36.153.4
- 199.36.153.5
- 199.36.153.6
- 199.36.153.7
Once you’ve created your A record for the domain of your choice, you need to also create a CNAME record in the googleapis.com zone for *.googleapis.com that points to the A record that you created.
What this does is allow you to access Google APIs and services via the DNS name you choose.
Now, with that said, there are some Google APIs and services that are provided via a few additional domain names, including *.gcr.io, *.gstatic.com, and pki.goog. In such cases, you’d follow a similar setup for those domains after you’ve configured your choice of private or restricted.
For example, if you need to use gcr.io to access a particular service or API, you’d create a zone for gcr.io in your DNS or in Cloud DNS. You’d then create an A record for the domain and point it at the same IPs you configured for private or restricted – whichever you setup previously.
You’d then need to create a CNAME record that points *.gcr.io to the A record that you created for the zone. The CNAME record would essentially point *.gcr.io to gcr.io.
You could then use the gcr.io domain to access additional services. You’d need to follow this same process for any domain you use to access Google APIs and services.
Join me in the next lesson, where we’ll take a look at routing and firewalls when configuring Private Google Access.
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.