Network controls in GCP vs. on-premises: Not so different after all

If you’re used to managing an on-premises network, moving to managing one in Google Cloud Platform (GCP) can be daunting. Some controls are similar, but often configuration (or what configuration implies) is different enough that you’ll need to take a step back and figure out what's different. In this post we’ll take you on a short tour of some of the native GCP network security controls that you’re likely familiar with on-premises and explain what’s different when you’re using those controls with GCP. When you use the GCP network, your services can benefit from global reachability at high speed and a highly flexible environment. And you can skip managing network equipment such as routers and switches.

GCP's network construct is known as a virtual private cloud (VPC) network. VPC networks, including their associated routes and firewall rules, are global resources. They are not associated with any particular region or zone, making it easier to get flexibility and high performance for your GCP workloads. But you’ll still have essential components to understand to make sure your cloud network is correctly configured. Here are the key areas to explore.

Subnets

As with an on-premises network, a VPC network can be subdivided into subnets, or subnetworks. A GCP subnet has a primary IP address range defined as a contiguous private RFC 1918 CIDR block. In GCP, each subnet that you create is associated with a region. Networks can contain one or more subnets in any given region. Subnets can extend across zones within a region. This diagram shows a global VPC network with subnets divided into various GCP regions.

To define and create a subnet within a VPC network, use the GCP console or the gcloud CLI. If you’ve ever wished it was easier to extend a subnet range after creating it and assigning IP addresses to resources, then GCP has you covered—you can extend a subnet range without disrupting running services. For example, you can expand a subnet with a prefix mask of /20 to a prefix max of /16 without having to reconfigure your existing workload.

Routes

Routing is the process where network packets are directed from their source toward their destination through intermediate network nodes. When you’re managing an on-premises network, these intermediate network nodes are typically network hardware devices such as routers, gateways or firewalls.

Routing on GCP is carried out through Google's software-defined network (SDN). GCP routes tell the VPC network where to send packets destined for a particular IP address. When you create a network, it has default routes created that let instances in a network reach each other across subnets as well as for internet traffic. You can also add user-defined routes for specific destination ranges that direct traffic to a VPN tunnel, a specially configured instance, or some other destination that you can configure using the console or the gcloud CLI.

A route alone is not enough to get a packet to its destination. You’ll need to configure firewall rules to permit the packet to reach its destination.

Firewalls

With a traditional on-premises stateful firewall, you have a firewall within your network, and all traffic between subnets or the internet passes through it. With these on-premises firewalls, you’re required to configure a set of rules that set up access lists between source and destination IP addresses or ports. You configure actions for each rule: allow (accept), drop (deny), track and log. Many of these firewalls have additional functionality, but all have the core ability to define the rules.

The difference when using GCP networking is that every VPC network functions as a distributed firewall. Firewall rules are defined at the network level and connections are allowed or denied on a per-instance basis. You can think of GCP firewall rules as existing not only between your instances and other networks, but between individual instances within the same network.

GCP firewalls are stateful, and as with traditional on-premises firewalls, also provide the core capability of setting up accept/deny rules. However, there are some other GCP firewall configuration capabilities that are definitely worth understanding to give you a lot more flexibility.

One feature is the ability to set up source and target filtering rules for ingress rules by using service accounts. A service account represents an identity associated with a Compute Engine virtual machine (VM) instance. This means that you focus on setting up rules where the source or destination is an identity rather than an IP address. When you set up a rule with a service account as the source, it matches connections that have a source IP address the same as the primary internal IP address of the instances you created with that service account. Where the target is a service account, the rule is assigned only to instances in the network that were created by that service account. This adds flexibility and helps reduce human error by allowing the configuration of firewalls by intent. For example, if you name your service accounts so they reflect their role, you are essentially telling the web servers (a service account ID = web server) to communicate with the application servers (service account application servers).You do not need to worry about IP addresses.

Another option for firewall routing with GCP is network tags, which are a way for networks to identify which instances are subject to certain firewall rules and network routes. Network tags are less secure than service accounts, but they’re a good fit for specific use cases with less stringent security requirements, like development configurations. You cannot use both service accounts and tags in the same rule.

VPN

An IPSec virtual private network (VPN) allows you to connect your VPC network to your physical, on-premises network or to another cloud provider. At the on-premises site, you will need an IPSec VPN gateway. At the GCP end, the Cloud VPN lets you set up a virtual VPN gateway running in GCP, which allows you to forward packets through the VPN. This can be configured via the console or the gcloud CLI.

When configuring the VPN between your on-premises network and a VPC network, you can dynamically advertise routes using the internet routing protocol Border Gateway Protocol (BGP) through the VPN connection established with GCP. In GCP, you’ll create BGP peering between the on-premises network and a Cloud Router on GCP, dynamically exchanging all relevant routes. At the on-premises end, you therefore need to configure a VPN gateway or router with BGP capabilities.

This diagram shows how this setup works in practice:

If you’re interested in learning more in general about GCP networking products, Data center professionals: networking is a great starting place. And to get a deeper understanding of using VPNs with GCP, read the Cloud VPN documentation.