How to restrict internet connectivity on a Compute Engine instance while still allowing access to public Google APIs

When creating a Compute Engine virtual machine instance in Google Cloud, by default the instance is assigned both an internal and an external (internet-facing) IP address.  This allows the instance to communicate with computers and systems on the internet, and allows systems on the internet to communicate with it.  However, there may be situations, usually involving sensitive workloads or compliance issues, where certain levels of internet access are either not desirable or not allowed.  Complicating the issue, these same workloads, while requiring isolation from the internet, may still require access to Google services that are accessed via the internet.  For example, a backend finance application may be required to be isolated from the internet, but may use the Google BigQuery API for analytics, or the Google Maps Platform for geospatial analysis.  This article discusses the various options for restricting access to the internet while optionally retaining access to Google services.

Restricting internet ingress

If you would like to ensure that no traffic from the internet can reach your Compute Engine instance, while allowing the instance to be able to reach the internet, the most secure way to achieve this is via a Google Cloud NAT gateway.  Cloud NAT will allow your instance to reach sites on the internet, while denying inbound traffic initiated from the internet from reaching your instance.  For example, this configuration would be useful in situations where your instance is not providing services to the internet (i.e. your server is not acting as a web server), but needs to use internet-based APIs.

Configuring Cloud NAT is a relatively simple procedure:

• Launch the Google Cloud console.
• Click the menu in the upper left corner of the blue bar (three horizontal lines)
• Scroll down to the Networking section.
• Choose Network services.
• Click Cloud NAT. 
• If you have no Cloud NAT instances configured, click the Get Started link, otherwise click the Create Cloud NAT Gateway link.
• Feel free to name the gateway whatever you’d like, but be sure to follow Google’s naming conventions (only lowercase letters, numbers and hyphens). 
• Select your network and region. 
• Cloud NAT requires a Cloud Router, so click the Cloud Router option and choose Create new router. 
  • Enter the name for your Cloud Router and click Create.
• You can leave the rest of the options at their default and click Create. 

Once this is done, be sure to remove the external IP address from your Compute Engine instance and it should automatically begin using the NAT Gateway.  Keep in mind that Cloud NAT is a regional service, so if your network has subnets in multiple regions, you will need to create a NAT gateway in each of the regions you wish to use it in.

Restricting all internet access

While the above configuration may be sufficient for certain workloads, others may require more stringent security in which no internet access should be allowed.  However, these same workloads may still need to access specific Google services such as Google BigQuery APIs or Google Maps Platform APIs.  In this case, Google provides Private Google Access, a method for accessing public Google services that does not require internet access.

Private Google Access is enabled at the subnet level.  To configure:

• Launch the Google Cloud console.
• Click the menu in the upper left corner of the blue bar (three horizontal lines)
• Scroll down to the Networking section.
• Choose VPC network.
• Click VPC networks.
• Click your VPC network and ensure that the Subnets tab is selected.
• Click on the subnet you wish to configure.
• Click the Edit button
• Set Private Google Access to On
• Click Save to accept your changes. 

Repeat this process for any other subnets that may require it.  As in the last section, be sure to remove the external IP address from your Compute Engine instance.  This will prevent traffic between the instance and the internet, but will allow the instance to programmatically access public Google APIs.

Firewalls and routing

Removing the external IP address is not the only way to control internet access for a Compute Engine instance.  One can keep the external IP address and instead configure firewall rules to limit access.  However, while firewall rules are extremely powerful and flexible, they are more complex to configure and maintain, and as such can be more prone to misconfiguration.  If inbound internet access is not necessary, removal of the external IP address combined with a NAT gateway is preferred to blocking inbound access via a firewall rule.

If the need is to create the most secure configuration possible, the route to the default Internet gateway can be removed entirely.  This will ensure that no traffic will be allowed to or from the internet, as there will be no route for the traffic to follow.  However, this method should only be used for networks that must be completely isolated from everything.  Not only does it affect every instance in every subnet of the virtual network, removal of the default internet gateway blocks access to Google services and APIs, as both Private Google Access and NAT Gateway require the default route to the internet to be in place in order to operate.

Summary

The Google Cloud Platform is an extremely powerful and versatile tool for virtually any workload, and it can be configured in a variety of ways to allow access to necessary systems while blocking unnecessary access to or from the internet.  To create Compute Engine instances that can access everything on the internet, including Google API’s, while ensuring that no internet traffic can reach the instance, Google Cloud offers the NAT Gateway.  To block inbound and outbound internet traffic while still allowing access to Google APIs, consider enabling Private Google Access.  To block traffic to and from everything outside the virtual private network including Google APIs, consider removing the route to the default internet gateway.  And finally, for the most fine grained control, consider firewall rules.