Hierarchical firewall policies are organization-level policy objects that group multiple firewall rules together. They allow administrators to apply consistent security controls across many Virtual Private Cloud (VPC) networks in one or more projects. These policies attach to the organization node or to individual folders, and once attached, their rules cascade downward to all child folders, projects, VPC networks, and virtual machine (VM) interfaces within that scope.
Google Cloud provides three types of firewall policies. Hierarchical firewall policies are organization-level resources that attach to the organization or to a folder; their rules automatically apply to all VPC networks beneath them in the resource hierarchy. Global network firewall policies are project-level resources that apply to all regions and must be explicitly associated with a VPC network before their rules take effect. Regional network firewall policies work like global policies but apply only to a specific region, and they must be associated with a VPC network in that same region. Choose the policy type based on whether the security control needs organization-wide scope or project-specific, region-specific granularity.
Each regular VPC network has an enforcement order that determines when firewall rules are evaluated. The AFTER_CLASSIC_FIREWALL order (the default) causes VPC firewall rules to be evaluated before rules in global and regional network firewall policies. The BEFORE_CLASSIC_FIREWALL order reverses this, evaluating global and regional network firewall policy rules before VPC firewall rules. This ordering matters because the first matching rule that permits or denies traffic wins. Administrators can change the enforcement order at the network level to fit different security architectures.
Access to hierarchical firewall policies is controlled by specific IAM roles. The compute.orgFirewallPolicyAdmin role lets users create, modify, and delete hierarchical firewall policies and their rules. The compute.orgSecurityResourceAdmin role, when granted at the organization or folder level, permits administrators to associate a policy with that resource. The compute.orgFirewallPolicyUser role allows administrators to use individual policies associated with a resource but does not grant association permissions. Viewing effective firewall rules requires roles such as compute.networkAdmin, compute.securityAdmin, or compute.viewer, which include the getEffectiveFirewalls permissions.
A hierarchical firewall policy must be associated with an organization or folder before its rules are enforced on VMs within that scope. Once associated, the policy applies to all VPC networks under that organization or folder. Administrators can add, remove, and modify rules individually within a policy; changes are applied in the order commands are executed, not atomically. For extensive changes that must take effect simultaneously, the recommended approach is to clone the policy to a temporary policy, make changes to the clone, then copy the rules back to the original policy before reassigning. Policies can be moved between folders as organizational structures evolve, but policies owned by a folder are deleted if that folder is deleted.
When hierarchical firewall policies are associated with resources in the organization hierarchy, the rules from all applicable policies combine with VPC firewall rules to form the effective firewall rules for each VM. Predefined rules with the lowest priority are automatically added to hierarchical firewall policies to handle connections that do not match any explicitly defined rule; these rules pass unmatched traffic down to lower-level policies or network rules. Within each policy, rules are evaluated from highest to lowest priority, where priority 0 is the highest. The evaluation order follows the network firewall policy enforcement order setting (BEFORE_CLASSIC_FIREWALL or AFTER_CLASSIC_FIREWALL). More specific rules must have higher priorities than general rules to ensure they are evaluated first.
In Shared VPC configurations, VM interfaces connected to a host project network are governed by the hierarchical firewall policy rules of the host project, not the service project. Even when service projects reside in a different folder than the host project, VM interfaces in the shared network still inherit rules from the host project folder’s hierarchical firewall policies. Security controls defined at the host project level take precedence over service project-level controls for shared network traffic. The host project administrator typically manages the firewall policy associations for the shared network.
When VPC Network Peering connects VPC networks from different organizations, each VM interface inherits the policies from its own VPC network’s hierarchy. The peered VPC networks maintain separate policy hierarchies, and traffic between them is evaluated against the firewall rules of the respective source and destination VPC networks. There is no unified hierarchical policy that spans the peering relationship. Administrators configuring cross-organization peering must ensure that both sides have appropriate firewall policy rules to permit the desired traffic flows.
Security profile groups are organizational-level containers that hold security profiles for Layer 7 inspection, including URL filtering and intrusion detection and prevention. A firewall policy rule can reference a security profile group using the apply_security_profile_group action, which redirects matched traffic to a firewall endpoint for inspection. Each security profile group can contain one URL filtering profile and one threat prevention profile. The firewall endpoint evaluates threat prevention first if it detects a possible threat in HTTP(S) message headers, then processes URL filtering for remaining traffic. These groups add an additional layer of inspection beyond the allow/deny decisions of basic firewall rules.
Hierarchical firewall policies allow organization administrators to define and enforce consistent firewall rules across the entire Google Cloud resource hierarchy. These policies attach to organization or folder nodes and cascade downward to all child folders, projects, VPC networks, and VM instances within those scopes. Cloud Next Generation Firewall (Cloud NGFW) evaluates these rules systematically, ensuring organization-wide security baselines take precedence over lower-level project configurations.
A hierarchical firewall policy is an organization-level resource container of firewall rules that does not take effect until associated with an organization or folder node. Once attached, the policy’s rules automatically cascade down to protect all VM interfaces and VPC networks within that resource hierarchy branch. Hierarchical firewall policies are parented by an organization or folder, meaning policy ownership is distinct from policy attachment; a single policy owned by one folder can be associated with multiple separate folders across the organization. Resource ancestry directly determines firewall inheritance in specialized network topologies. In a Shared VPC architecture, VM interfaces connected to a shared subnet inherit the hierarchical firewall policies applied to the host project’s folder hierarchy, not the service project’s folder hierarchy. In a VPC Network Peering architecture, VM interfaces in each peered VPC network continue to evaluate and inherit the hierarchical firewall policies from their own respective organization or folder hierarchy.
Cloud NGFW evaluates firewall rules based on a strict numeric priority order, where 0 represents the highest possible priority and larger numbers represent lower priority. When network traffic enters or leaves a VM network interface, rules are evaluated sequentially from the highest-priority rule (lowest integer) to the lowest-priority rule. If traffic matches the criteria of a rule, the rule’s specified action is applied immediately, terminating further rule evaluation unless a specific evaluation-continuation action is configured. Every rule within a specific policy must possess a unique priority value. System administrators commonly space priority integers (such as 100, 200, and 300) to allow operational room for inserting future rules between existing ones. Policy rules evaluate criteria such as Layer 4 protocols and ports, direction of traffic (ingress or egress), source or destination IP CIDR ranges, and target restrictions such as service accounts or secure tags (with GCE_FIREWALL purpose).
Hierarchical firewall rules define traffic processing using three core actions: allow, deny, and goto_next. An allow action permits the matching packet and stops all subsequent firewall evaluation for that connection. A deny action blocks the matching packet and halts further evaluation across all subsequent policy layers. The goto_next action bypasses the remaining rules within the current hierarchical policy and passes packet evaluation down to the next level of the hierarchy. The evaluation flow proceeds in order: first, traffic is evaluated against the organization-level hierarchical firewall policy rules in numeric priority order. If traffic matches a goto_next rule or matches no explicit rules, evaluation proceeds to the folder-level policy. If unhandled or delegated via goto_next across all descending folder policies, evaluation cascades down to project-level network firewall policies and classic VPC firewall rules. If traffic fails to match any user-defined rule in a hierarchical policy, Cloud NGFW triggers built-in predefined rules at the lowest possible priority, automatically handing off the connection to lower-level policies.
VPC networks maintain a network firewall policy enforcement order setting that governs how project-level policies interact with classic VPC firewall rules after hierarchical evaluation completes. The AFTER_CLASSIC_FIREWALL mode (default) evaluates classic VPC firewall rules before evaluating global and regional network firewall policies. The BEFORE_CLASSIC_FIREWALL mode evaluates global and regional network firewall policies before classic VPC firewall rules. Regardless of this project-level configuration, all organization-level and folder-level hierarchical firewall policy rules evaluate before any project-level network firewall policies or VPC firewall rules.
Managing hierarchical firewall policies requires specific IAM roles to separate policy administration from resource attachment. The compute.orgFirewallPolicyAdmin role allows administrators to create, modify, delete, and move hierarchical firewall policies across organization and folder nodes. Associating a policy to an organization or folder requires compute.orgSecurityResourceAdmin on the target resource hierarchy node, combined with either compute.orgFirewallPolicyAdmin or compute.orgFirewallPolicyUser on the policy resource. To determine the active rule set on running infrastructure, administrators use the compute.networks.getEffectiveFirewalls and compute.instances.getEffectiveFirewalls permissions (included in roles such as compute.networkAdmin, compute.securityAdmin, and compute.networkViewer). These commands generate the full sequence of effective firewall rules applied to specific VPC networks and VM instances, ordering rules across all inherited organization, folder, and project layers.
Hierarchical firewall policy enforcement is the process by which firewall rules defined at the organization and folder levels are applied to VPC networks and VM instances. Troubleshooting this enforcement involves verifying that the correct rules are applied in the intended order and identifying where configurations may block or allow traffic unexpectedly. You diagnose issues by tracing the effective policy rules—the final set of rules a VM interface receives after evaluation through the entire resource hierarchy.
The effective firewall rules for a VM are the consolidated result of evaluating all applicable rules from the organization, ancestor folders, and the VPC network itself. Rules are evaluated in a strict, top-down order: first from the hierarchical firewall policy associated with the organization, then from policies associated with each folder down to the project’s parent folder, followed by global network firewall policies, regional network firewall policies, and finally VPC firewall rules. Within each policy, rules are evaluated by priority, from the lowest number (highest priority) to the highest. The first rule with an allow or deny action that matches the traffic direction, source, destination, and protocol stops all further evaluation. A goto_next action defers evaluation to the next level in the hierarchy, which is critical for delegating control to lower-level administrators.
To diagnose a connectivity problem, you must trace a packet’s path through the rule hierarchy to see which rule ultimately allows or denies it. You use tools like Firewall Insights and Policy Analyzer to verify intended enforcement. For example, if SSH traffic is blocked to a VM, you would check the effective rules for that VM’s network interface to see if a high-priority deny rule from an organization policy overrides a project-level allow rule. You specifically look for rules that shadow or conflict with others. A common misconfiguration occurs when a broad deny rule at a high level (like the organization) has a higher priority than a specific allow rule at a lower level (like a folder), causing the intended allowance to never be evaluated.
The Firewall Rules Logging feature provides logs for allow and deny rules (but not goto_next rules), which you can query in Cloud Logging to confirm whether traffic matched a specific rule. To get a comprehensive view, you use the gcloud compute firewall-policies list-associations command or the console to see which policies are attached to which resources. More powerfully, you use the get effective firewall rules commands—both for a network (gcloud compute networks get-effective-firewalls) and for a specific VM interface (gcloud compute instances get-effective-firewalls). These commands output all rules from all policy levels that apply to that resource, presented in their evaluation order. This output allows you to audit the exact rule sequence and identify gaps, such as a missing allow rule or an overly permissive deny rule from a folder policy that should have been overridden.
StudyCerts
StudyCertsallow or deny action stops further evaluation.goto_next action bypasses remaining rules in the current policy and passes evaluation to the next level in the hierarchy, such as from a folder policy to project-level policies.gcloud compute instances get-effective-firewalls command to list all inherited rules in evaluation order, and Firewall Rules Logging records allow and deny matches.A hierarchical firewall policy is attached to the organization or a folder and applies to all VPC networks under that node automatically. A global network firewall policy is a project-level resource that must be explicitly associated with a specific VPC network and applies only to that network.
goto_next action affect rule evaluation?The goto_next action stops evaluation of the remaining rules in the current hierarchical policy and passes the packet to the next level in the hierarchy (for example, from a folder policy to the project-level network firewall policies). This allows higher-level policies to delegate decisions to lower-level administrators.
AFTER_CLASSIC_FIREWALL versus BEFORE_CLASSIC_FIREWALL enforcement order?Use AFTER_CLASSIC_FIREWALL (default) when you want VPC firewall rules to be evaluated before global and regional network firewall policies. Use BEFORE_CLASSIC_FIREWALL when you want the project-level network firewall policies to take precedence over classic VPC firewall rules. Both settings are overridden by the organization and folder hierarchical policies, which are always evaluated first.
Use the gcloud compute instances get-effective-firewalls command, which outputs all rules from organization, folder, global network, regional network, and VPC firewall levels in the order they are evaluated. This command requires the compute.instances.getEffectiveFirewalls permission.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills