Secure Internet Access with Cloud NAT

If a VM needs access to the Internet, you need to set up (in the simplest case) a number of elements. To begin, configure a route to the Internet gateway by setting a route to CIDR range 0.0.0.0/0 as the Next Hop Internet Gateway; then you need to provide the VM with an external IP address.

This configuration results in VMs that are directly accessible on the Internet, which is not always desirable for security reasons. If you do allow outbound Internet access, you need to set up network address translation (NAT). You can either configure this yourself or use the Cloud NAT service. If you do so, Cloud NAT provides Internet connectivity for the following services:

• Compute engine
• Private Google Kubernetes Engine (GKE) cluster
• Cloud run by serverless VPC access
• Cloud function by serverless VPC access
• App Engine by serverless VPC access

Cloud NAT is a managed service and, as such, offers high availability of at least 99.9 percent. It is also regionally resilient to zone failure. Figure 3 shows the use of Cloud NAT in a global setup with two regions: us-east1 and europe-west1. One Cloud NAT instance is set up for each region and VPC. An instance like this can provide Internet connectivity for the entire VPC (Figure 3, right) or only for individual subnets (subnet 1 in the us-east1 region).

Figure 3: The Cloud NAT architecture lets VMs communicate with the Internet. © Google [2]

To set up Cloud NAT, you need to do the following: Switch to Network services | Cloud NAT in the Networking section (Figure 4). If you are creating a Cloud NAT instance for the first time in the project, click the Get Started link. Once the wizard has launched, assign a name for your instance.

Figure 4: When creating a Cloud NAT instance, secondary ranges allow a VM to have multiple IP addresses.

Next, select the VPC to which you want Cloud NAT to connect; then, configure a region and specify the cloud router to use. When you do this, Cloud NAT adds itself to the cloud router so it can publish routes through the router. Finally, you need to define the subnets that will be using the NAT router. You can choose individual subnets or opt for the whole VPC, and you can specify which secondary ranges are allowed to use Cloud NAT. Secondary ranges are used, for example, when a VM hogs multiple IP addresses; examples of this type of activity include VMs with Docker or Kubernetes clusters, where each pod receives an IP address from the VPC.

Internet Access with VMs

Cloud NAT eliminates the need for public IP addresses for Internet access. If you only want to access Google services, you can do without Cloud NAT. Although many Google services have public IP addresses, Google provides a technology known as Private Google Access to access them directly with a VPC. This method only requires appropriate DNS entries and routing.

More specifically are DNS domains for which you need to set up private zones. For example, most Google APIs reside in the googleapis.com domain. To match this, you can create a zone for that domain in your Cloud DNS. In the zone, you then need to set up an A record for IP addresses 199.36.153.8, 199.36.153.9, 199.36.153.10, and 199.36.153.11.

Additionally, you need a CNAME record for *.googleapis.com that points to the A record you created. Now you just need the routing. To do this, go to the VPC's administration page, switch to the Routing tab and add a route with the target 0.0. 0.0/0, whose next hop is the default Internet gateway.

Protecting Serverless Workloads

In addition to VMs, serverless workloads (Cloud Functions, Cloud Run, or App Engine) also need access to a VPC from time to time, which is often accompanied by a desire to isolate all network traffic from the Internet. Cloud Functions can be handled by VPC Serverless Access , and Cloud Run can at least be implemented for Cloud Functions and Cloud Run. To do this, you first need to reserve a /28 subnet in the corresponding VPC.

Next, deploy the Serverless VPC Access connector. With its help, you can ultimately access VPC resources; managed Google resources, such as Cloud SQL or Memory with private IP addresses; or local networks if hybrid connectivity is available. As soon as the Serverless VPC Access connector is up and running, you need to sharpen up in terms of security, because you will want all incoming and outgoing network traffic to pass through the connector, preventing access by public IP addresses.