A Layperson’s Guide to GCP Network Firewalling

A companion to OSI Layer 3/Layer 4 firewalling in GCP

Firewalls have been, and continue to be, an evergreen technical domain for managing network communications for decades. Despite how storied firewalls have been in managing network communications over the years, firewall management details can vary wildly between vendors and cloud providers.

In this article, we’ll focus on network firewalling and its rules and policy management in Google Cloud Platform. The intent is to provide you, the reader, with a comprehensive landscape of firewall configuration options in GCP as a starting point. A core outcome, using this broader point of view, is to encourage better design choices around enforcement and lifecycle management for GCP firewalling.

By the end, you should be armed with a foundational overview of what’s involved with GCP firewall management and understand:

• The Anatomy of a Firewall Rule
• GCP Firewalling Foundational Facts
• Firewall policies and how they enable firewall rules management at scale

Reader Assumptions

This article is going to assume that the reader has foundational working knowledge of networking concepts. (e.g., the OSI model, classful and classless subnets, network protocols) The article also assumes that the reader has had some exposure to general firewall management, be it on another cloud platform, vendor solution, and the like.

Another assumption is that the reader is familiar with the GCP Resource Hierarchy as this information is relevant to using firewall policies.

Additionally, while this article assumes that the reader has limited knowledge of GCP firewalling, this article may also act as a refresher or companion reference for experienced GCP users to springboard into different facets of GCP firewalling.

The Anatomy of a Firewall Rule

Before we dive into some of the more particular details around GCP firewalling, it’s important to level set firewall rules terminology used in GCP.

Let’s run through what a firewall rule looks like in GCP. The graphic below will act as a visual map to describe the firewall rule components:

Foundational facts about GCP Firewalling

Regardless of the technical domain, while a solution may offer ways to apply different types of grouping and conditionals to help organizations achieve configurations aligned with technical and non-technical requirements, there are foundational truths that inform how the configuration is modeled and firewalling is no exception to that. These truths for firewalling in GCP are:

• Firewall rules are managed using the Compute Engine API
• All firewall rules are stateful
• Firewall rules can be attached to a VPC network or a firewall policy
• All firewall rules have a configurable priority
• GCP has a collection of globally blocked or limited traffic, managed by Google

Firewall rules are managed using the Compute Engine API

Firewall rules are managed under the Compute Engine API umbrella. If you’re provisioning from scratch, you’ll fumble across this fact using the Cloud Console within a new project.

1. Cloud Console has a discrete interface for VPC networking…

2. …that when you load it without enabling the Compute Engine API, the Cloud Console redirects you…

3. …to enable the Compute Engine API

All GCP firewall rules are stateful

In GCP, when a firewall rule is created and traffic matches the rule, the return traffic for that match is permitted. You cannot configure a firewall rule to deny associated response traffic.

Firewall rules can be attached to a VPC network or a firewall policy

Once the Compute Engine API is enabled, firewall rules can be configured and directly attached to the VPC network for filtering. Firewall rules attached to a VPC network are not readily portable to other VPC networks in other GCP projects.

If you need to manage firewall rules at scale for your organization, it is recommended that you use firewall policies. Firewall policies are a container for firewall rules that can be attached to supported GCP resources within the Resource Hierarchy. We’ll expand on firewall policies later in this article.

All firewall rules have a configurable priority

GCP firewall rules have a configurable priority associated with them. The configured priority determines which order rules are evaluated. As such, the principle of a rule being used based on “first hit, not best fit” applies.

Firewall rules matching is done by “first hit, not best fit”

The phrase First Hit, Not Best Fit is used to characterize and emphasize how the configuration of firewall priority on a rule is important.

Let’s create an academic example to demonstrate this. In this scenario, you were interested in denying network access to services from a contiguous half of a private subnetwork’s address space (192.168.1.0/25). Below is a simplified and egregiously configured list of firewall rules and their priority to attempt to meet that objective:

While rule 3500 is valid, it is superseded by rule 2500, which will permit those clients who you want to deny. Flipping the rule definitions of rules 2500 and 3500 will result in the desired behavior:

Contextual differences on firewall rule priority

Firewall rules in GCP will always have a priority associated with them. However, the constraints around how priorities are configured differ depending on usage context. See the table below which illustrates the differences between firewall rule and firewall policy usage contexts:

Regarding duplicate firewall rules configured within a VPC Network Firewall, there is an order of operations that reconciles what takes precedence in the event a set of rules share a common priority.

Being mindful of these priority rules is not necessary for a firewall policy. This is because all rules defined within a firewall policy must have discrete priorities. This condenses the consideration for firewall rules order in a firewall policy down to “First hit, not best fit” when crafting rules for a firewall policy.

Additional details around GCP firewalling

Targets and Filters can use service accounts and tags

In addition to using traditional CIDR notation for address ranges to define in rules, you may also use service accounts and tags (network tags on VMs or secure tags²).

Auto-configured firewall rules

For the ‘default’ VPC network that is created with a GCP project, there are a collection of predefined rules that are automatically applied and enforced. The rules permit all intra-network traffic within the VPC, as well as permissive rules allowing ICMP, SSH, and RDP access to GCP resources.

Implicit firewall rules

The following implicit firewall rules are catch-all default rules that are applied if none of the configured firewall rules match a traffic flow:

• Implied allow egress rule
• Implied deny ingress rule

Google manages a collection of globally allowed, blocked, or limited traffic for GCP

With Google advocating for Shared Fate along with Shared Responsibility when operating in GCP, it’s important to understand, or at least have reference to, what GCP is always allowing, blocking, and limiting as part of its service provider offering.

Firewall policies and management at scale

Let’s pivot to talking about firewall policies in GCP. So far, we’ve focused on attaching firewall rules to a VPC network. However, let’s say your organization’s scale is outstripping the administrative capabilities provided for managing firewall rules in a GCP project. Problems you’d be encountering include:

• Inconsistent application of common firewall rules across multiple projects in a GCP organization
• Delegating a level of autonomy to teams within your organization to self-manage firewall rules in your GCP projects without violating the organization’s desired firewall hardening posture

Enter firewall policies. Firewall policies are a logical container consisting of firewall rules. Those rules containers can then be attached to supported GCP resources within the hierarchy.

There are three types of firewall policies:

1. Hierarchical Firewall Policies
2. Network Firewall Policies
3. Regional Firewall Policies

Fortunately, there are a lot of common traits across the different policy types. We’ll focus on those and then raise some key differences in policy types.

Common facts regarding GCP Firewall Policy Types

Creating a policy does not automatically apply the configured rules to any network

When creating a new firewall policy, the policy is not attached to any GCP resource by default. Only when the policy is attached to a supported resource, will the rules in the firewall policy be evaluated.

Rules evaluation for attached firewall policies follow the resource hierarchy

While firewall policy association constraints vary across the different firewall policy types, they all adhere to the GCP Resource Hierarchy for parent/child resource relationships. Having working knowledge of how the resource hierarchy is structured in GCP will lead to more impactful design and architectural choices throughout your management lifecycle on Google Cloud.

Firewall policies enable centralized rules management and governance

Firewall policies enable one policy to many resource relationships. These one-to-many relationships allow for consistent management and enforcement of firewall rules across your GCP organization.

Additionally, firewall policies introduce a new action, goto_next. When a rule is configured with this action, the rules processing is deferred to a child policy or rule downstream. This allows for a layered approach on what rules are globally enforced. This logical flow diagram illustrates a chain of firewall policies and rules mapped onto a generic GCP resource hierarchy:

For all firewall policy types, there are a set of IPv4 and IPv6 rules with the lowest priority and an action of goto_next. This differs from the implicit firewall rules, which will result in an allow or deny. Additionally, while you may author a firewall policy to supersede these implicit rules, they cannot be modified or deleted.

Having covered the common features of each firewall policy, here are the key differences for each firewall policy type:

Hierarchical firewall policy

The biggest distinction of a hierarchical firewall policy is where the policies are created and what resources they can be associated with. A hierarchical policy can be created at and attached to organization and folder nodes.

Network firewall policy

A network firewall policy is created at the VPC level. Policies created at the VPC level can be shared with other VPC networks that have a common GCP project.

While hierarchical firewall policy authoring may be similar to authoring firewall rules in a VPC network, network firewall policies have very stark differences when contrasted against a VPC firewall rule:

Secure tags are another name for Resource Manager tags. Using secure tags allows for access control to be managed by IAM. If your organization has a requirement of marshaling what tags to use via IAM, then you’ll need to use Network firewall policies, as Network tags for VMs do not have an access control mechanism.

Regional network firewall policy

Finally, there are regional network firewall policies. They share a lot of the same traits as a (Global) Network firewall policy except:

• They target one and only one region
• Only one regional firewall policy can be associated within a network

Closing Remarks

After providing a lay of the land around GCP Firewalling, you should now be:

• Armed with foundational information around GCP firewalling, increasing or reinforcing your understanding of firewall rules and policy management
• Able to conceptualize how to rationalize risk and manage GCP firewall defaults in your GCP organization and/or projects
• Review your resource hierarchy and rationalize a strategy to effectively use firewall policies in your GCP organization
• More effectively interpret the firewall related recommendations made in the Networking Security section for VPC architecture and best practices