A to Z of Google Cloud Platform a personal selection — F is for firewalls

I am a firm believer in defence in depth and in this post just wanted to talk about the compute engine firewalls which is a crucial part of that approach when using Compute Engine on GCP.

I”m going to assume you know how a firewall is typically implemented on premise by managing what traffic can and cannot flow between subnets and the internet by implementing a set of rules that allow or disallow traffic passing through it based on ports, protocol and source & target subnets or IP addresses.

The GCP firewall is actually pretty similar in application in that firewalls are associated with a network so each network in a GCP project has its own firewall controlling connectivity .

All GCP projects have a default network with an associated default firewall rule . This default firewall has the following rules:

default-allow-internal

Allows network connections of any protocol and port between instances on the network.

default-allow-ssh

Allows SSH connections from any source to any instance on the network over TCP port 22.

default-allow-rdp

Allows RDP connections from any source to any instance on the network over TCP port 3389.

default-allow-icmp

Allows ICMP traffic from any source to any instance on the network

When you create a new network however there are no firewall rules permitting connections of any type. so after creating a new network, you need to create firewall rules for it to allow connectivity of any sort with your instances.

An instance must be associated with a network and thus by default the firewall rules associated with that network apply to the instances in that network. If you do not explicitly state the network that the instances should be deployed into using the — network flag the instance will be deployed ( or associated depending on how pedantic you want to be — deployed just sounds more natural to me when discussing this) into the default network and connectivity subjected to the firewalls rules associated with that.

Note :You can add additional firewall rules to the default network

A GCP project by default has up to 5 networks ( you can get this upped by making a quota request) and each network can have multiple firewall rules associated with them.

GCP also has the concept of sub networks. This allows you to partition your network into chunks ( a subnetwork ) that have non-overlapping RFC1918 ranges i.e private IPv4 address ranges that you can define and manage within a single network. A project can have up to 100 subnetworks that can be arranged as you see fit i.e all in one network or spread across a number of networks ( up to 5 networks in total )

As I don’t want to get sidetracked talking about subnets ( I know too late!) hopefully the image below from the docs gives you an idea of how you can configure subnetworks within and across zone boundaries .

I’d also suggest taking time out to read through the docs on subnetworks before planning out how you intend to configure any application using Compute engine in case you feel you want to make use of this feature .

Subnetworks do not change what I have already described about how firewall rules work but you may be asking how you can apply firewall rules that are specific to subnets then if the rules apply to the network. Tags are the answer! Using tags means you can create additional isolation between subnetworks by selectively allowing only certain instances to communicate. If you arrange for all instances in a subnetwork to share the same tag, you can specify that tag in firewall rules to simulate a per-subnetwork firewall. For example if you have a subnet called subnet-a , you can tag all instances in subnet-a with the tag my-subnet-a and use that tag in firewall rule target-tags or as source ranges. The docs walk through a nice example of using tags and subnets with firewall rules