Identity & Security

Managing cloud firewalls at scale with new Hierarchical Firewall Policies

#security

Following up our previous blog post, we are excited to announce that hierarchical firewalls are generally available. Google Cloud’s hierarchical firewall policies provide new, flexible levels of control so that you can benefit from centralized control at the organization and folder level, while safely delegating more granular control within a project to the project owner. 

Hierarchical firewall policies

Hierarchical firewalls provide a means to enforce firewall rules at the organization and folder levels in the GCP Resource Hierarchy.  This allows security administrators at different levels in the hierarchy to define and deploy consistent firewall rules across a number of projects so that they are applied to all VMs in currently existing and yet-to-be-created projects.

Being able to manage the most critical firewall rules in one place also frees project level administrators from having to keep up with changing organization wide policies.

Because management of firewalls is a balance between security and per-application needs, we have designed this product with features that allow organization-level and folder-level security administrators to delegate as much fine grained control to the project and network level administrators as desired. For maximum flexibility there is also a feature to allow organization-level and folder-level administrators to make exceptions for certain networks.

Hierarchical firewall policies.jpg

IAM requirements 

Cloud Identity and Access Management (IAM) lets administrators authorize who can take action on specific resources, giving you full control and visibility to manage Google Cloud resources centrally. There are three key IAM roles involved in hierarchical firewalls management:

  • compute.orgSecurityResourceAdmin which controls who can associate a policy to a folder or organization in the resource hierarchy.

  • compute.orgFirewallPolicyAdmin which controls who can create and modify the Security Policy.

  • compute.orgFirewallPolicyUser which controls who can view and use a security policy.

For more details on IAM please review Cloud Identity and Access Management (IAM).

Organization firewall policies

Whereas VPC firewall rules are directly associated with a network or VPC, hierarchical firewalls are defined in an organization security policy resource which simply acts as a container for firewall rules.  It is important to note that rules defined in an organization security policy are not enforced until the policy is associated with a node in the hierarchy. This opens up several other use cases, for instance if an administrator wants to test a firewall policy thoroughly before it is applied company-wide, the firewall policy could be tested on a lower node in the hierarchy and once it is validated thoroughly, it could be associated with a higher node in the hierarchy; and in case that the policy needed to be removed it would be as easy as to remove the association. In cases where several interrelated rules need to be enforced at the same time, the firewall policy structure allows easy batch rule updates that was not possible with the VPC firewall rules. 

A single organization security policy instance can be associated with multiple folders such that a modification to the rules in the organization security policy will be applied to all currently associated nodes. On the other hand, a hierarchy node can only have one organization security policy associated at any given time.

single organization security policy.jpg

How rules are evaluated

Hierarchical firewalls are enforced at the VM level like VPC firewalls, and they are not applied at the edge as traditional firewalls would be. Hierarchical firewalls are configured as a firewall policy, which contains a set of rules that are evaluated before VPC firewalls; you could think of it as a set of rule chains that get evaluated in sequence according to the GCP resource hierarchy level at which each rule chain is applied. So based on that, rules applied at the organization level have a higher priority than child folders or rules applied to lower levels in the hierarchy, so firewall policies configured at a higher level in the hierarchy will always have priority over lower levels in the hierarchy. That means that as part of the evaluation process, if a firewall rule within a firewall policy matches, the action is taken and firewall policies at lower levels in the hierarchy (including VPC firewalls) are ignored unless the rule action is “go to next”.

Firewall rules that are part of the organization-level security policy will be evaluated first, followed by the respective folder security policies defined in the hierarchy, and finally the VPC network firewall rules. 

Within each policy, the firewall rules are evaluated according to the priority given, the same way as defined today. 

  • Upon a match in a rule defined in the Org security policy, the action defined in the rule ("allow", deny", "go to next") will be taken. If the action is “go-to-next-level”, then the firewall evaluation will skip the rest of the rules in the same policy and move directly to firewall rules defined at the next level in the hierarchy.

  • The same logic will apply subsequently across all folder security policies defined in the hierarchy. Upon a match in a rule defined in the folder security policy, the action defined in the rule ("allow", “deny", "go to next ") will be taken. 

  • If there is no match in any rule defined in the Org security policy, the next level of the hierarchy will be evaluated. If there is no match in any firewall rule that applies to the specific VM, the default and implied firewall rules will apply. 

New attributes for hierarchical firewalls

With the introduction of hierarchical firewalls, we are introducing target resources with two additional attributes that can be used. One of them is target networks, which gives the administrator granular control over which VPC networks are configured with that rule and therefore restrict the firewall rule to VMs in the specified networks only or to create an exception for that VPC. Additionally, we also support the option of target service accounts to allow the administrator to define a targeted group of VMs to which certain firewall rules apply as well. It is important to point out that source service accounts and network tags are not supported in the hierarchical firewall policy rules.

New attributes for hierarchical firewalls.jpg

Effective Firewall Policy and Logging

While project-level administrators manage network firewalls, they typically do not have permission to see which firewall policies are associated with folders and/or organization, and this could pose a challenge especially when troubleshooting is required. To address this need, we have provided the get-effective-firewalls API that allows users to examine the complete set of firewall rules that apply to an instance or a network. Additionally, you have the option to log firewall rule activity at the organization and folder levels just as you do at the VPC level. Please check our documentation for further details on that.

Key takeaways

Hierarchical firewalls allow configuring rules at the Organization and Folder levels, in addition to firewall rules at the VPC level. The main benefits of leveraging hierarchical firewall policies is management simplicity, consistency and reliability, since it allows a central set of rules to be automatically enforced across all networks in the defined scope, thus managing multiple environments becomes simpler and more effective. 

It is recommended to initially create hierarchical firewall policies in a lower level in the hierarchy, and when satisfied with the behavior, the association can be changed to a higher level. 

However, carefully configure firewall policies at the organization level—the organization is the highest level in the hierarchy and thus any firewall policies added to this level will affect the entire organization (i.e. all projects and VPCs belonging to the referred organization). A misconfigured firewall rule can bring down the entire organization or allow traffic that was not supposed to, so for that matter it is important to be thorough when defining rules at the organization level.

To learn more about hierarchical firewalls, please read our documentation. Additionally, to see how we're advancing intelligent automation in network security, check our recent blog post. To learn more about cloud security, tune in to the Google Cloud Security Talks today.