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:
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.
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 |
---|---|
Enforcement |
A rule toggle that acts as a means to enforce or disable a firewall rule.
This is helpful for, but not limited to:
|
Rule Direction |
Can be INGRESS or EGRESS only. Firewall rules in GCP are stateful, automatically permitting the return traffic for an established connection between a client and a target. Directionality is relative to the resource the rule becomes attached to (VPC network, hierarchical policy, etc) |
Priority |
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. |
Action |
Can be configured with allow or deny for firewall rules. Rules configured within firewall policies can use the verb goto_next . |
Target |
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:
|
Filter |
|
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. |
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 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:
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.
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.
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.
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:
Priority | Action | Direction | Target | Filter |
---|---|---|---|---|
1500 | allow |
INGRESS |
All Networks | 172.16.0.0/16 |
2500 | allow |
INGRESS |
All Networks | 192.168.1.0/24 |
3500 | deny |
INGRESS |
All Networks | 192.168.1.0/25 |
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:
Priority | Action | Direction | Target | Filter |
---|---|---|---|---|
1500 | allow |
INGRESS |
All Networks | 172.16.0.0/16 |
2500 | deny |
INGRESS |
All Networks | 192.168.1.0/25 |
3500 | allow |
INGRESS |
All Networks | 192.168.1.0/24 |
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.
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).
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.
The following implicit firewall rules are catch-all default rules that are applied if none of the configured firewall rules match a traffic flow:
egress
ruledeny ingress
ruleUnderstanding 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.
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.
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:
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:
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.
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.
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 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:
goto_next
. The GCP project also uses Firewall Rules for additional rules coverage.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:
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.
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 | |
---|---|---|
Priority | Unique | Duplication allowed |
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 |
Reuse | Yes | 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.
Finally, there are regional network firewall policies. They share a lot of the same traits as a (Global) Network firewall policy except:
After providing a lay of the land around GCP Firewalling, you should now be: