Hierarchical firewall policies overview

Hierarchical firewall policies let you create and enforce a consistent firewall policy across your organization. You can assign hierarchical firewall policies to the organization as a whole or to individual folders. These policies contain rules that can explicitly deny or allow connections, as do Virtual Private Cloud (VPC) firewall rules. In addition, hierarchical firewall policy rules can delegate evaluation to lower-level policies or VPC network firewall rules with a goto_next action.

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.

Specifications

  • Hierarchical firewall policies can be specified at the organization and folder nodes.
  • Hierarchical firewall policies are containers for firewall rules. When you associate a policy with the organization or a folder, all rules are immediately applied. You can swap policies for a node, which atomically swaps all the firewall rules applied to virtual machine (VM) instances under that node.
  • Rule evaluation is hierarchical based on resource hierarchy. All rules associated with the organization node are evaluated, followed by those of the first level of folders, and so on.
  • Hierarchical firewall policy rules have a new goto_next action that you can use to delegate connection evaluation to lower levels of the hierarchy.
  • Hierarchical firewall policy rules can be targeted to specific VPC networks and VMs by using target resources. This lets you create exceptions for groups of VMs.
  • A new feature lets you see which firewall rules are actually applied to a specific network or VM interface, which helps with compliance and debugging.

Resource hierarchy

You create and apply firewall policies as separate steps. You can create and apply firewall policies at the organization or folder nodes of the resource hierarchy. A firewall policy rule can block connections, allow connections, or defer firewall rule evaluation to lower-level folders or VPC firewall rules defined in VPC networks.

  • Organization is the top-level node in the resource hierarchy in Google Cloud where you can create or associate hierarchical firewall policies. All folders and VPC networks in the organization inherit this policy.

  • Folders are mid-level nodes in the Google Cloud resource hierarchy, between the organization and projects, where you can create or assign hierarchical firewall policies. All folders and VPC networks in a folder inherit its associated policy.

  • A project lives under a folder or the organization. You can move projects between nodes in an organization. Projects contain VPC networks. Hierarchical firewall policies cannot be assigned to projects, only to the organization or folders.

  • A VPC network is the Google Cloud partition for isolated internal IP space communication. This is the level at which routes and traditional VPC firewall rules are specified and applied. Hierarchical firewall policy rules can override network firewall rules, or they can delegate connection evaluation to them.

By default, all hierarchical firewall policy rules apply to all VMs in all projects under the organization or folder where the policy is associated. However, you can restrict which VMs get a given rule by specifying a target network or target service account.

The levels of the hierarchy at which firewall rules can now be applied are represented in the following diagram. The yellow boxes represent hierarchical firewall policies that contain firewall rules, while the white boxes represent VPC firewall rules.

Hierarchical firewall policies containing rules (yellow boxes)
        at the organization and folder levels and VPC firewall
        rules at the VPC network level
Hierarchical firewall policies containing rules (yellow boxes) at the organization and folder levels and VPC firewall rules at the VPC network level

Rule evaluation

Hierarchical firewall policy rules are enforced at the VM level as are VPC firewall rules. That is, they are not applied at the network's edge as traditional firewalls would be.

Google Cloud evaluates hierarchical firewall policy rules and VPC firewall rules in this order:

  1. If a firewall policy is associated with an organization, Google Cloud evaluates that policy's rules applied to the VM. Each rule results in connections being allowed or denied, or the rule can instruct the firewall evaluation to go to the next level of the hierarchy, which is either a folder or a VPC network.
  2. Google Cloud evaluates policy rules associated with each folder, starting with the top folder under the organization and working down through child folders if present.

    Evaluation of each rule results in connections being allowed or denied, or the rule can instruct the firewall evaluation to go to the next level of the hierarchy, which is either another folder or a VPC network.

  3. Finally, VPC firewall rules are evaluated. VPC firewall rules either allow or deny connections.

Firewall rule resolution flow
Firewall rule resolution flow

Hierarchical firewall policy details

Hierarchical firewall policy rules are defined in a firewall policy resource that acts as a container for firewall rules. The rules defined in a firewall policy are not enforced until the policy is associated with a node (an organization or a folder).

A single policy can be associated with multiple nodes. If you modify a rule in a policy, that rule change applies to all currently associated nodes.

Only one firewall policy can be associated with a node. Hierarchical firewall policy rules and VPC firewall rules are evaluated in a well-defined order.

Policy names

When you create a new policy, Google Cloud automatically generates an ID for the policy. In addition, you also specify a display name for the policy. When using the gcloud interface to update an existing policy, you can reference either the system-generated ID or a combination of the display name and your organization ID. When using the API to update the policy, you must provide the system-generated ID.

Hierarchical firewall policy rule details

Hierarchical firewall policies contain rules that generally work the same as VPC firewall rules, but there are a few differences.

Priority

  • Unlike VPC firewall rules, where several rules can have the same priority, hierarchical firewall policy rules must have a specified priority, and each priority must be unique within a firewall policy.

  • Hierarchical firewall policy rules do not have names. Instead, the firewall policy itself has an ID and a name, and each rule therein has a unique priority number.

  • Within a hierarchical firewall policy, the firewall rules are evaluated in priority order, starting with the highest priority (lowest number) rule. Thus, a rule with priority 0 in a policy assigned to the organization node overrides any other rule in the organization.

Action on match

  • allow
    A hierarchical firewall policy allow rule overrides any deny rule with a lower priority or at a lower level in the hierarchy. Use allow rules in an organization or folder policy to unconditionally allow certain types of connections to all VMs under that node in the hierarchy.

    For example, if you have centrally managed probers that monitor all VMs in your organization, you can create an allow rule at the organization level to ensure that requests from the probers' IP addresses are not blocked by any network in any project.

  • deny
    A hierarchical firewall policy deny rule overrides any allow rule with a lower priority or at a lower level in the hierarchy.

    For example, if you want to make sure that none of the VMs in your organization can be accessed from a specific IP range, you can create a deny rule for that range.

  • goto_next
    Directs the firewall to move the firewall evaluation to the next lower level of the hierarchy. You can use this to delegate specific types of connections for lower levels to manage.

Target networks

You can restrict a hierarchical firewall policy rule to VMs in only specified networks. Specifying the target network in the rule gives you control over which VPC networks are configured with that rule. Combined with goto_next or allow, it lets you create exceptions for specific networks when you want to define an otherwise restrictive policy.

Target service accounts

You can specify a target service account for a rule. Such rules are applied only to VMs owned by the specified service account. Hierarchical firewall policy rules do not support targeting by instance tags.

Protocols and ports

Similar to VPC firewall rules, you must specify one or more protocol and port constraints when you create a rule. When specifying TCP or UDP in a rule, you can specify the protocol, the protocol and a port, or the protocol and a port range; you cannot specify only a port or port range. For ICMP, specify icmp. Firewall rules do not support specifying ICMP types and codes.

Logging

Logging for hierarchical firewall policy rules works the same as for VPC Firewall Rules Logging except for the following:

  • The reference field includes the security policy ID and a number indicating the hierarchical level of the node to which the policy is attached. For example, 0 means that the policy is applied to an organization, and 1 means that the policy is applied to a top-level folder under the organization.

  • Logs for hierarchical firewall policy rules include a target_resource field that identifies the VPC networks to which the rule applies.

Logging can only be enabled for allow and deny rules; it cannot be enabled for goto_next rules.

Pre-defined rules

All hierarchical firewall policies have two pre-defined goto_next rules with lowest priority. These rules are applied to any connections that do not match an explicitly defined rule in the policy, causing such connections to be passed down to lower-level policies or network rules.

  • An egress rule with very low priority (2147483646) that sends processing of the connection to the next lower level of evaluation (goto_next).
  • An ingress rule with a very low priority (2147483647) that sends processing of the connection to the next lower level of evaluation (goto_next).

These pre-defined rules are visible, but cannot be modified or deleted. These rules are different from the implied and pre-populated rules of a VPC network.

Identity and Access Management (IAM) roles

The following roles are relevant to hierarchical firewall policies.

Role name Description
compute.orgSecurityPolicyAdmin Granted at the organization level or to a folder, allows users to create, update, and delete hierarchical security policies and their rules. It also allows the admin to associate a policy with a node if they also have the compute.orgSecurityResourceAdmin role on that node.
compute.orgSecurityResourceAdmin Granted at the organization level or to a folder, allows folder-level administrators to associate a policy with that node. Administrators must also have the compute.orgSecurityPolicyUser role on the node that owns the policy in order to make use of it.
compute.orgSecurityPolicyUser Granted at the organization level or to a folder, allows administrators to make use of policies associated with the organization or folder. Users must also have the compute.orgSecurityResourceAdmin role on the target node to associate a policy with that node.
compute.securityAdmin
compute.viewer
compute.securityReadOnly
compute.networkUser
compute.networkViewer
Allows users to view the firewall rules applied to the network or instance.
Includes the compute.networks.getEffectiveFirewalls permission for networks and the compute.instances.getEffectiveFirewalls for instances.

In the following example, Joe can create, modify, and delete any hierarchical firewall policy in the policies folder, but he cannot attach the hierarchical firewall policy to a folder because he does not have the orgSecurityResourceAdmin role on any folder.

However, because Joe granted Mary permissions to use policy-1, she can list and associate that hierarchical firewall policy with the dev-projects folder or any of its descendants. The orgSecurityPolicyUser role does not grant permission to associate the policies to any folders; the user must also have the orgSecurityResourceAdmin role on the target folder.

policy-1 example
policy-1 example

Managing hierarchical firewall policy resources

Because a hierarchical firewall policy only defines a set of firewall rules and not where they are applied, you can create these resources in a different part of the hierarchy from the nodes that they apply to. This lets you associate a single hierarchical firewall policy resource with multiple folders in the organization.

In the following example, policy-1 is applied to the dev-projects and corp-projects folders and so is enforced on all projects in those folders.

Policy location and association
Policy location and association

Modifying a policy's rules

You can add, remove, and modify rules in a policy. Each change is done individually; there is no mechanism for batch updating rules in a policy. Changes are applied in roughly the order that the commands are executed, although this is not guaranteed.

If you are making extensive changes to a hierarchical firewall policy and need to ensure that they're applied at the same time, you can clone the policy to a temporary policy and assign the temporary policy to the same nodes. You can then make your changes to the original, and then assign the original back to the nodes. For the steps to do this, see Copying rules from one policy to another.

In the following example, policy-1 is attached to the dev-projects folder, and you would like to make several changes that apply atomically. Create a new policy named scratch-policy, and then copy all of the existing rules from policy-1 to scratch-policy for editing. After you finish editing, copy all the rules from scratch-policy back to policy-1.

Modify a policy
Modify a policy

Moving a policy

Hierarchical firewall policies, like projects, are parented by a folder or organization resource. As your folder scheme evolves, you might need to move a hierarchical firewall policy to a new folder, perhaps before a folder deletion. Policies owned by a folder are deleted if the folder is deleted.

The following diagram illustrates moving a policy between nodes associations or the evaluation of rules in the policy.

Move a policy
Move a policy

Associating a hierarchical firewall policy with a folder

A hierarchical firewall policy is not enforced unless it is associated with an organization or folder node. After it is associated, it is applied to all VMs in all networks under that organization or folder.

Associate a policy
Associate a policy

Changes to the resource hierarchy

Changes to the resource hierarchy might take some time to propagate through the system. We recommend that you avoid simultaneous updates to the hierarchical firewall policy attachments and the resource hierarchy because networks might not immediately inherit the hierarchical firewall policy defined in the new location in the hierarchy.

Moving a policy
Moving a policy

For example, if you are moving the dept-A folder from the dev-projects folder to the eng-projects folder and changing the association of policy-1 to eng-projects instead of dev-projects, be sure to not disassociate policy-1 from dev-projects at the same time. If the dev-projects folder loses its hierarchical firewall policy association before all VPC networks under it have had their ancestry updated, for a short period of time those VPC networks are not protected by policy-1.

Using hierarchical firewall policies with Shared VPC

In Shared VPC scenarios, a VM interface connected to a host project network is governed by the hierarchical firewall policy rules of the host project, not the service project.

VM in Shared VPC
VM in Shared VPC

Even if the service projects are under a different folder than the host project, the VM interfaces in the shared network still inherit from the host project folder rules.

Service project VMs inherit rules from host project
Service project VMs inherit rules from host project

Using hierarchical firewall policies with VPC Network Peering

In VPC Network Peering scenarios, the VM interface associated to each of the VPC networks inherits the policies in the hierarchy in the respective VPC networks. Following is a VPC Network Peering example where the VPC peered networks belong to different organizations.

VMs inherit from respective networks
VMs inherit from respective networks

Effective firewall rules

Because connections are governed by both hierarchical firewall policy rules and VPC firewall rules, it is helpful to see all firewall rules that affect an individual network or individual VM interface.

Project-level administrators might not have permission to view rules in hierarchical firewall policies that affect their VMs. However, if a user has permissions to see firewall rules for a network, that user can see all rules that apply to the network, even if the rules are inherited from a folder or the organization.

Network effective security policy

You can view all firewall rules applied to a VPC network. The list includes all rules inherited from hierarchical firewall policies and all rules applied from the VPC network.

Instance effective firewall rules

You can view all firewall rules applied to a VM's network interface. The list includes all rules inherited from hierarchical firewall policies and all rules applied from the interface's VPC network.

The rules are ordered from the organization level down to the VPC rules. Only rules that apply to the VM interface are shown. Rules in other policies are not shown, so a user cannot see the overall security policy of the organization.

What's next