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
Following defense in depth, cloud providers often provide a suite of complementary security services to achieve networking security at different layers of the OSI model. In GCP, this includes VPC Service Controls, BeyondCorp (for Zero Trust), and Cloud Armor for Layer 7 network protection.
This article is focused on OSI Layer 3/Layer 4 network protection using GCP firewall rules. Additionally, firewall features described in this article will focus on generally available (GA) features.
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.
Level setting GCP-specific firewall terms are foundational to this article. Since this is a companion reference, it is important that you’re able to springboard into GCP documentation from here in a predictable and reliable manner.
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:
|Firewall Rule Component||Description|
|A rule toggle that acts as a means to enforce or disable a firewall rule.
This is helpful for, but not limited to:
|A whole number that specifies the firewall rule’s priority during rules processing.
The lower the number, the higher the priority since it puts it towards the top of the list.
|Can be configured with
|Target and Filter are used to match what originators of network traffic are interesting for this firewall rule.
The Target and Filter context changes based on direction:
Ports and Protocols
|A combination of network protocols (i.e.: TCP, UDP, ICMP) and protocol ports to further refine the selection criteria for a firewall rule.|
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.
Example 1 (images above): Ordered screen snips showing how the Cloud Console guides users to the appropriate API to enable (in this case, Compute Engine API) networking services in a GCP project.
If you’re working with GCP resources in a brownfield environment for the first time, this detail may not be immediately apparent while using the Cloud Console.
gcloud commands, however, do a better job of self-describing that firewall management is under 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.
Return traffic must match the source IP, destination IP, source port, destination port, and protocol of the accepted request traffic, but with the source and destination addresses and ports reversed.
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:
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
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:
|Firewall Rule Attached To||Highest Priority1||Lowest Priority1||Duplicate Rule Priority?|
|VPC Network Firewall||0||65535||Allowed|
|GCP Firewall Policy||0||2147483647||Denied|
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 tags2).
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
Understanding what these defaults are is important when trying to level set the desired security posture you’re trying to achieve to align with technical and non-technical requirements.
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:
- Hierarchical Firewall Policies
- Network Firewall Policies
- 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
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:
|Network firewall policy rules||VPC firewall rules|
|Service account||Target service account only (no source service account)||Yes|
|Tag||Secure tag||Network tag|
|Name and description||Policy name, policy and rule description||Rule name and description|
|Batch update||Yes(policy clone, edit, and replace functions)||No|
|Quota||Attribute count||Rule count|
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
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
Published: September 22, 2022
· 13 min read
Senior Cloud Security Consultant
- Network Security,
- Firewall Policies
- Share on Twitter, LinkedIn, or email
The information presented in this article is accurate as of September 22, 2022. Follow the ScaleSec blog for new articles and updates.
ScaleSec is a service-disabled, veteran-owned small business (SDVOSB) for cloud security and compliance that helps innovators meet the requirements of their most scrutinizing customers. We specialize in cloud security engineering and cloud compliance. Our team of experts guides customers through complex cloud security challenges, from foundations to implementation, audit preparation and beyond.