Firewall policies

Firewall policies let you group several firewall rules so that you can update them all at once, effectively controlled by Identity and Access Management (IAM) roles. These policies contain rules that can explicitly deny or allow connections, as do Virtual Private Cloud (VPC) firewall rules.

Hierarchical firewall policies

Hierarchical firewall policies let you group rules into a policy object that can apply to many VPC networks in one or more projects. You can associate hierarchical firewall policies with an entire organization or individual folders.

For hierarchical firewall policy specifications and details, see Hierarchical firewall policies.

Global network firewall policies

Global network firewall policies let you group rules into a policy object applicable to all regions (global). After you associate a global network firewall policy with a VPC network, the rules in the policy can apply to resources in the VPC network.

For global network firewall policy specifications and details, see Global network firewall policies.

Regional network firewall policies

Regional network firewall policies let you group rules into a policy object applicable to a specific region. After you associate a regional network firewall policy with a VPC network, the rules in the policy can apply to resources within that region of the VPC network.

For regional firewall policy specifications and details, see Regional network firewall policies.

Policy and rule evaluation order

Rules in hierarchical firewall policies, global network firewall policies, regional network firewall policies, and VPC firewall rules are implemented as part of the VM packet processing of the Andromeda network virtualization stack. Rules are evaluated for each network interface (NIC) of the VM.

The applicability of a rule doesn't depend on the specificity of its protocols and ports configuration. For example, a higher priority allow rule for all protocols takes precedence over a lower priority deny rule specific to TCP port 22.

In addition, the applicability of a rule doesn't depend on the specificity of the target parameter. For example, a higher priority allow rule for all VMs (all targets) takes precedence even if a lower priority deny rule exists with a more specific target parameter; for example—a specific service account or tag.

Determine policy and rule evaluation order

The order in which the firewall policy rules and VPC firewall rules are evaluated is determined by the networkFirewallPolicyEnforcementOrder flag of the VPC network that is attached to the VM's NIC.

The networkFirewallPolicyEnforcementOrder flag can have the following two values:

  • BEFORE_CLASSIC_FIREWALL: If you set the flag to BEFORE_CLASSIC_FIREWALL, the global network firewall policy and regional network firewall policy are evaluated before VPC firewall rules in the rule evaluation order.

  • AFTER_CLASSIC_FIREWALL : If you set the flag to AFTER_CLASSIC_FIREWALL, the global network firewall policy and regional network firewall policy are evaluated after VPC firewall rules in the rule evaluation order. AFTER_CLASSIC_FIREWALL is the default value of the networkFirewallPolicyEnforcementOrder flag.

To change the rule evaluation order, see Change policy and rule evaluation order.

Default policy and rule evaluation order

By default, and when the networkFirewallPolicyEnforcementOrder of the VPC network that is attached to the VM's NIC is AFTER_CLASSIC_FIREWALL, Google Cloud evaluates rules applicable to the VM's NIC in the following order:

  1. If a hierarchical firewall policy is associated with the organization that contains the VM's project, Google Cloud evaluates all applicable rules in the hierarchical firewall policy. Because rules in hierarchical firewall policies must be unique, the highest priority rule that matches the direction of traffic and Layer 4 characteristics determines how the traffic is processed:

    • The rule can allow the traffic. The evaluation process stops.

    • The rule can deny the traffic. The evaluation process stops.

    • The rule can send the traffic for Layer 7 inspection (apply_security_profile_group) to the firewall endpoint. The decision to allow or drop the packet then depends on the firewall endpoint and the configured security profile. In both the cases, the rule evaluation process stops.

    • The rule can permit processing of rules defined as described in the next steps if either of the following is true:

      • A rule with a goto_next action matches the traffic.
      • No rules match the traffic. In this case, an implied goto_next rule applies.

  2. If a hierarchical firewall policy is associated with the most distant (top) folder ancestor of the VM's project, Google Cloud evaluates all applicable rules in the hierarchical firewall policy for that folder. Because rules in hierarchical firewall policies must be unique, the highest priority rule that matches the direction of traffic and Layer 4 characteristics determines how the traffic is processed—allow, deny, apply_security_profile_group, or goto_next—as described in the first step.

  3. Google Cloud repeats the actions of the previous step for a hierarchical firewall policy associated with the next folder that is closer to the VM's project in the resource hierarchy. Google Cloud first evaluates rules in hierarchical firewall policies associated with the most distant folder ancestor (closest to the organization), and then evaluates rules in hierarchical firewall policies associated with the next (child) folder closer to the VM's project.

  4. If VPC firewall rules exist in the VPC network used by the VM's NIC, Google Cloud evaluates all applicable VPC firewall rules.

    Unlike rules in firewall policies:

    • VPC firewall rules have no explicit goto_next or apply_security_profile_group action. A VPC firewall rule can only be configured to allow or deny traffic.

    • Two or more VPC firewall rules in a VPC network can share the same priority number. In that situation, deny rules take precedence over allow rules. For additional details about VPC firewall rules priority, see Priority in the VPC firewall rules documentation.

    If no VPC firewall rule applies to the traffic, Google Cloud continues to the next step—implied goto_next.

  5. If a global network firewall policy is associated with the VPC network of the VM's NIC, Google Cloud evaluates all applicable rules in the firewall policy. Because rules in firewall policies must be unique, the highest priority rule that matches the direction of traffic and Layer 4 characteristics determines how the traffic is processed—allow, deny, apply_security_profile_group, or goto_next—as described in the first step.

  6. If a regional network firewall policy is associated with the VPC network of the VM's NIC and region of the VM, Google Cloud evaluates all applicable rules in the firewall policy. Because rules in firewall policies must be unique, the highest priority rule that matches the direction of traffic and Layer 4 characteristics determines how the traffic is processed—allow, deny, or goto_next—as described in the first step.

  7. As a final step in the evaluation, Google Cloud enforces the implied allow egress and implied deny ingress VPC firewall rules.

The following diagram shows the resolution flow for firewall rules.

Firewall rule resolution flow.
Figure 1. Firewall rule resolution flow (click to enlarge).

Change policy and rule evaluation order

Google Cloud provides you the option to change the default rule evaluation process by swapping the order of the VPC firewall rules and network firewall policies (both global and regional). When you do this swap, global network firewall policy (step 5) and regional network firewall policy (step 6) are evaluated before VPC firewall rules (step 4) in the rule evaluation order.

To change the rule evaluation order, run the following command to set the networkFirewallPolicyEnforcementOrder attribute of the VPC network to BEFORE_CLASSIC_FIREWALL:

gcloud compute networks update VPC-NETWORK-NAME \
    --network-firewall-policy-enforcement-order BEFORE_CLASSIC_FIREWALL

For more information, see the networks.patch method.

Effective firewall rules

Hierarchical firewall policy rules, VPC firewall rules, and global and regional network firewall policy rules control connections. You may find it helpful to see all the firewall rules that affect an individual network or VM interface.

Network effective firewall rules

You can view all firewall rules applied to a VPC network. The list includes all of the following kinds of rules:

  • Rules inherited from hierarchical firewall policies
  • VPC firewall rules
  • Rules applied from the global and regional network firewall policies

Instance effective firewall rules

You can view all firewall rules applied to a VM's network interface. The list includes all of the following kinds of rules:

  • Rules inherited from hierarchical firewall policies
  • Rules applied from the interface's VPC firewall
  • Rules applied from the global and regional network firewall policies

The rules are ordered from the organization level down to the VPC network. Only rules that apply to the VM interface are shown. Rules in other policies are not shown.

To view the effective firewall policy rules within a region, see Get effective firewall policies for a network.

Predefined rules

When you create a hierarchical firewall policy, a global network firewall policy, or a regional network firewall policy, Cloud NGFW adds predefined rules to the policy. The predefined rules that Cloud NGFW adds to the policy depend on how you create the policy.

If you create a firewall policy using the Google Cloud console, Cloud NGFW adds the following rules to the new policy:

  1. Goto-next rules for private IPv4 ranges
  2. Predefined Google Threat Intelligence deny rules
  3. Predefined geolocation deny rules
  4. Lowest possible priority goto-next rules

If you create a firewall policy using the Google Cloud CLI or the API, Cloud NGFW adds only the lowest possible priority goto-next rules to the policy.

All predefined rules in a new firewall policy purposefully use low priorities (large priority numbers) so you can override them by creating rules with higher priorities. Except for the lowest possible priority goto-next rules, you can also customize the predefined rules.

Goto-next rules for private IPv4 ranges

  • An egress rule with destination IPv4 ranges 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, priority 1000, and goto_next action.

  • An ingress rule with source IPv4 ranges 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, priority 1001, and goto_next action.

Predefined Google Threat Intelligence deny rules

  • An ingress rule with source Google Threat Intelligence list iplist-tor-exit-nodes, priority 1002, and deny action.

  • An ingress rule with source Google Threat Intelligence list iplist-known-malicious-ips, priority 1003, and deny action.

  • An egress rule with destination Google Threat Intelligence list iplist-known-malicious-ips, priority 1004, and deny action.

To learn more about Google Threat Intelligence, see Google Threat Intelligence for firewall policy rules.

Predefined geolocation deny rules

  • An ingress rule with source matching geolocations CU,IR, KP, SY, XC, and XD, priority 1005, and deny action.

To learn more about geolocations, see Geolocation objects.

Lowest possible priority goto-next rules

You cannot modify or delete the following rules:

  • An egress rule with destination IPv6 range ::/0, priority 2147483644, and goto_next action.

  • An ingress rule with source IPv6 range ::/0, priority 2147483645, and goto_next action.

  • An egress rule with destination IPv4 range 0.0.0.0/0, priority 2147483646, and goto_next action.

  • An ingress rule with source IPv4 range 0.0.0.0/0, priority 2147483647, and goto_next action.

What's next