Hierarchical Firewall Policy Automation with Terraform

Firewall rules are an essential component of network security in Google Cloud. Firewalls in Google Cloud can broadly be categorized into two types; Network Firewall Policies and Hierarchical Firewall Policies. While Network Firewalls are directly associated with a VPC to allow/deny the traffic, Hierarchical Firewalls can be thought of as the policy engine to use Resource Hierarchy for creating and enforcing policies across the organization. Hierarchical policies can be enforced at the organization level or at the folder(s) level. Like Network Firewall rules, hierarchical firewall policy rules can allow or deny traffic AND can also delegate the evaluation to lower level policies or to the network firewall rules itself (with a go_next). Lower-level rules cannot override a rule from a higher place in the resource hierarchy. This lets organization-wide admins manage critical firewall rules in one place.

So, now let’s think of a few scenarios where Hierarchical Firewall policies will be useful

1. Reduce the number of Network Firewall: 

Example: say in xyz.com got 6 Shared VPCs based upon their business segments. It is a security policy to refuse SSH access to any VMs in the company, i.e. deny TCP port 22 traffic. With Network Firewalls, this rule needs to be enforced at 6 places (each Shared VPC). Growing number of granular Network firewall rules for each network segment means more touch points, i.e. means more chances of drift and accidents. Security admins get busy with hand holding and almost always become a bottleneck for even simple firewall changes. With Hierarchical firewall Policies, Security Admins can create a common/single policy to deny TCP port 22 traffic and enforce it to xyz.com org. OR explicitly target one/many Shared VPCs from the policy. This way a single policy can define the broader traffic control posture.  

2. Manage critical firewall rules using centralized policies AND safely delegate non-critical controls at VPC level

Example: At xyz.com SSH to GCEs is strictly prohibited and non-negotiable. Auditors need this. While allowing/denying TCP traffic to port 443 depends on which Shared VPC the traffic is going to. In this case security admins can create a policy to deny TCP port 22 traffic and enforce this policy to the xyz.com. Another policy is created for TCP port 443 traffic to say “go_next” and decide at the next lower level if this traffic is allowed. Then, have a Network Firewall rule to allow/deny 443 traffic at the Shared VPC level. 

This way Security Admin has broader control at a higher level to enforce traffic control policies and delegate where possible. Ability to manage the most critical firewall rules at one place also frees project level administrators (e.g., project owners, editors or security admin) from having to keep up with changing organization-wide policies. 

With hierarchical firewall policies, Security admin can centrally enforce, manage and observe the traffic control patterns.

Create, Configure and Enforce Hierarchical Firewall Policies

There are 3 major components of Hierarchical Firewall Policies; Rules, Policy and Association. 

Broadly speaking a “Rule” is a decision making construct to declare if the traffic should be allowed, denied or delegated to the next level for decision. “Policy” is a collection of rules, i.e. one or more rules can be associated with a Policy. “Association” tells the enforcement point of the policy in the Google Cloud resource hierarchy. 

These concepts are extensively explained on the product page.

A simple visualization of Rules, Policy and Association looks like

Infrastructure as Code (Terraform) for Hierarchical Firewall Policies

There are 3 Terraform Resources that need to be stitched together to build and enforce Hierarchical Firewall Policies.  

#1 Policy Terraform Resource - google_compute_firewall_policy

In this module the most important parameter is the “parent” parameter. Hierarchical firewall policies, like projects, are parented by a folder or organization resource. Remember this is NOT the folder where the policy is enforced or associated. It is just a folder which owns Policy(s) that you are creating. Using a Folder to own the hierarchical firewall policies, also simplifies the IAM to manage who can create/modify these policies, i.e. just assign the IAM to this folder. 

For a scaled environment it is recommended to create a separate “firewall-policy” folder to host all of your Hierarchical Firewall Policies.

Sample

You can get the Folder ID of the “firewall-policy” folder using below command

gcloud resource-manager folders list --organization=<your organization ID> --filter='<name of the folder>'

For example, if your firewall policy folder is called ‘firewall-policy’ then use 

gcloud resource-manager folders list --organization=<your organization ID> --filter='firewall-policy' 

#2 Rules Terraform Resource - google_compute_firewall_policy_rule

Most of the parameters in this resource definition are very obvious but there are a couple of them that need special consideration.

• disabled - Denotes whether the firewall policy rule is disabled. When set to true, the firewall policy rule is not enforced and traffic behaves as if it did not exist. If this is unspecified, the firewall policy rule will be enabled. 

• enable_logging - enabling firewall logging is highly recommended for many future operational advantages. To enable it, pass true to this parameter.

• target_resources - This parameter comes handy when you want to target certain Shared VPC(s) for this rule. You need to pass the URI path for the Shared VPC. Top get the URI for the VPC use this command 

Sample

Here is some sample Terraform code to create a Firewall Policy Rule with priority 9000 to deny TCP port 22 traffic from 35.235.240.0/20 CIDR block (used for identity aware proxy)

#3 Association Terraform Resource - google_compute_firewall_policy_association

In the attachment_target pass the folder ID where you want to enforce this policy, i.e. everything under this folder (all projects) will get this policy. In the case of Shared VPCs, the target folder should be the parent of your host project. 

Sample

Once these policies are enforced, you can see it on the console under “VPC Network->Firewall” as something like below.

In the Firewall Policy Folder, the created Hierarchical Firewall Policy will show up. Remember there are 4 default firewall rules that come with each policy, so even when you create a single rule in your policy, rule count will be 5, as shown in the panel below.

Go into the Policy to see the rules you created and association of the policy (shown in 2 panels). 

Summary

Hierarchical Firewall Policy simplifies the complex process of enforcing consistent traffic control policies across your Google Cloud environment. With Terraform modules and automation shown in this article, it gives Security admins ability to build guardrails using a policy engine and known Infrastructure as Code platform. 

Check out the Hierarchical Firewall Policy doc and how to use them.