Business Challenge
#73 covered the policies that attach above a project. These attach inside one. Global network firewall policies let you group rules into a policy object that can apply to all regions of a VPC network, and regional network firewall policies let you group rules into a policy object that can apply to a specific region of a VPC network. Said that way they sound like the same object at two radii, and the interesting material is everywhere except in that sentence.
Three things make these worth a post of their own. They occupy the one step of the firewall evaluation order that you can actually move. The switch that moves it is not on the policy. And a rule inside a policy is not a VPC firewall rule with extra packaging — four things about it are different, and one of them is missing from regional policies entirely.
Only if you changed the enforcement order, and by default you did not. Google Cloud supports two network firewall policy enforcement orders that control how rules are evaluated relative to classic VPC firewall rules, and the default is the one that runs the old rules first: AFTER_CLASSIC_FIREWALL (default): Evaluates classic VPC firewall rules before evaluating global and regional network firewall policies.
Correct approachTreat a migration into policies as two changes, not one. Until the network is flipped to BEFORE_CLASSIC_FIREWALL : Evaluates global and regional network firewall policies before evaluating classic VPC firewall rules, a stale broad allow rule in the VPC rule set is consulted first and can decide the packet before your policy is ever read. The policy is not wrong; it is downstream.
It is a property of the network. You set it with the networks.patch method and set the networkFirewallPolicyEnforcementOrder attribute of the VPC network, or with the matching --network-firewall-policy-enforcement-order flag on gcloud compute networks update. Since you can associate a global network firewall policy with multiple VPC networks, one policy can be evaluated early on one network and late on another.
Audit the attribute per network and store it next to the network definition, not next to the policy. A reviewer reading the policy cannot tell where in the order it sits, because that answer is not in the object they are reading.
You cannot. You can't use the apply_security_profile_group action in regional network firewall policies or regional system firewall policies. That is the action #73 introduced — the one that hands matched traffic to a firewall endpoint for deep inspection — and it exists in hierarchical and global policies only.
Correct approachDecide where inspection lives before you decide where the rules live. If the intended design is "all security controls in the regional policy, close to the workload", the inspection rules have to break that pattern and sit in the global or hierarchical policy instead, which also changes who can edit them.
Architecture
Four policy types now exist, and a single network attribute decides where two of them land in the order.
Where each one lives, and the asymmetry in how they attach
Global policies are project objects. Global network firewall policies are container resources for firewall rules, and each global network firewall policy resource is defined within a project. Attachment is the second step again, exactly as in #73: to apply global network firewall policy rules to a VPC network, you must associate the firewall policy with that VPC network, and if the firewall policy isn't associated with any VPC network, the rules in that policy have no effect. An unattached one has a name of its own — a firewall policy that is not associated with any network is an unassociated global network firewall policy.
Regional policies are narrower in scope and, counter-intuitively, looser in attachment. Regional network firewall policies are per-project, per-region objects that contain firewall rules, and they are collections of firewall rules that apply to a single region of one or more VPC networks. The asymmetry is in the cardinality: for global, each VPC network can be associated with only one global network firewall policy, while the quota list carries a regional network firewall policy associations per region per VPC network entry describing the maximum number of regional network firewall policies that you can associate with a region of a VPC network. One global policy per network; several regional policies per region of that network.
Both are confined to a project boundary. Make sure that the firewall policy and the associated networks belong to the same project for global, and for regional, the associated networks must match the policy type, and each associated VPC network must be in the same project as the regional network firewall policy. That phrase — match the policy type — is the RoCE case: regional network firewall policies support both regular VPC networks and Remote Direct Memory Access (RDMA) over converged ethernet (RoCE) VPC networks, where for VPC_POLICY , associate the regional network policy with regular VPC networks and for RDMA_ROCE_POLICY , associate the regional network policy with RoCE VPC networks. Regional is the only policy type in this post that reaches RDMA networks at all.
The fourth type, which you do not create
There is a policy type in your networks that you did not make and cannot edit. Regional system firewall policies are similar to regional network firewall policies, but they are managed by Google. They appear on demand: Google Cloud creates a regional system firewall policy in a region of a VPC network when a Google service requires rules in that region of the network, and Google Cloud can associate more than one regional system firewall policy with a region of a VPC network based on the requirements of Google services.
Three facts about them matter operationally. They are early — Google Cloud evaluates rules in regional system firewall policies immediately after evaluating rules in hierarchical firewall policies, which means before anything you can reorder. They are read-only with one exception: you can't modify a rule in a regional system firewall policy, except to enable or disable firewall rule logging. And they are free: you aren't charged for the evaluation of rules in regional system firewall policies. If a packet is being allowed and you cannot find the rule, this is the layer most likely to hold it.
Why This Architecture Holds Up
This is the part I had assumed was cosmetic and is not. The documentation prints the comparison directly, and every row is a behaviour change rather than a syntax change.
| Global network firewall policy rules | VPC firewall rules | |
|---|---|---|
| Priority number | Must be unique within a policy | Duplicate priorities allowed |
| Service accounts as targets | Yes | Yes |
| Service accounts as sources (ingress rules only) | No | Yes |
| Tag type | Secure tag | Network tag |
| Reuse across networks | Yes | No |
| Quota basis | Attribute count, by rule complexity | Rule count, regardless of complexity |
Read the third and fourth rows together and #72 stops transferring. That post compared targeting by network tag against targeting by service account, and inside a policy both halves of the comparison change: network tags are replaced by secure tags, and the source-service-account option that made service accounts symmetrical is gone. A rule you wrote as a VPC firewall rule with source-service-accounts has no direct translation into a policy rule.
The priority row is the easier one to miss and the one that will fail a deployment. Each rule in a firewall policy must have a unique priority, where VPC firewall rules let duplicates sit side by side and resolve arbitrarily. The range itself is unchanged from #70: the priority is an integer from 0 to 2,147,483,547 , inclusive. So a bulk migration of VPC rules into a policy needs a priority assignment pass, and a sparse numbering scheme is worth choosing up front rather than renumbering later.
Quota stops counting rules and starts counting attributes
This is the most practical finding in the post. A VPC firewall rule costs one rule against quota whether it names one port or forty. A policy rule costs the sum of its attributes, and the per-attribute table is specific: one count for each IP range, one for each protocol, one for each port or port range, one for each secure tag used as a source, one for each country code, sum of capacities of each address group — and 64 attribute counts for each FQDN object.
Google works two examples, and both are worth recomputing rather than trusting. The first is an ingress deny with two source ranges, one destination range, TCP and UDP, and port ranges 53-53 and 5353-5353: there are four protocol and port combinations: tcp:53-53 , tcp:5353-5353 , udp:53-53 , and udp:5353-5353, each costing two attributes, so two source ranges plus one destination range plus eight gives eleven. The second is the one to remember — three attributes for the source network context, one source range, one FQDN object, one protocol and one port range, totalling seventy, with the footnote that note that the two target secure tags are not counted.
Sixty-four of those seventy attributes are the single FQDN object. One rule naming one domain consumes more policy quota than twenty rules naming IP ranges, and nothing in the rule's appearance signals it. If a policy is approaching its attribute ceiling, the question is not how many rules it has — it is how many FQDN objects and how large the address groups are. Target secure tags, which is where a reader would reasonably expect the cost to be, are free.
The order, and the one step you can move
The fixed part first. Cloud NGFW always evaluates rules in hierarchical firewall policies and regional system firewall policies before it evaluates any other firewall rules. Nothing you configure changes that, which is the project-level restatement of #73's precedence guarantee. After those two steps, the network's enforcement order decides whether VPC firewall rules or these policies come next.
Within the policies the sequence is also fixed, and it runs outward-in: global, then regional. In a global network firewall policy, at most, one rule can match traffic, and when that rule delegates, goto_next : the rule evaluation continues to the regional network firewall policy step in the evaluation order. Then Cloud NGFW evaluates rules in regional network firewall policies that are associated with the region and VPC network of the target resource.
If nothing matches anywhere, the last step is the implied action, and it is not uniform. If the target resource is a network interface of a VM instance, the implied ingress action is deny, but if the target resource is a forwarding rule of an internal Application Load Balancer or internal proxy Network Load Balancer, the implied ingress action is allow. Egress is simpler: for egress traffic, the implied action is allow. That default-allow for internal load balancer forwarding rules is the kind of asymmetry that only shows up when you are debugging why a proxy accepted something a VM would have refused.
Creating a policy and putting it into force need different roles
The IAM split here is cleaner than #73's and worth copying into a permissions review. Creating, modifying and deleting a global policy all need the same grant: create a new global network firewall policy Compute Security Admin role ( roles/compute.securityAdmin ) on the project to which the policy belongs. Attaching it does not — associate a policy with a network Compute Network Admin role ( roles/compute.networkAdmin ) on the project where the policy will live.
So the security team can author rules it cannot activate, and the network team can activate rules it cannot write. Visibility is separated again: if granted for a network, allows users to view the list of global network firewall policies describes the network admin's read access, while the viewer roles carry only the effective-rules permissions. Three distinct capabilities — write the policy, attach the policy, see what is in force — and three different grants.
Two smaller things that round out the model
A new policy is safe to attach, for the same reason as in #73. When you create a global network firewall policy, Cloud Next Generation Firewall (Cloud NGFW) adds predefined rules with the lowest priority to the policy, and the regional page says the same of itself: when you create a regional network firewall policy, Cloud Next Generation Firewall adds predefined rules with the lowest priority to the policy. Those rules delegate rather than block — these rules are applied to any connections that don't match an explicitly defined rule in the policy, causing such connections to be passed down to lower-level policies or network rules.
And the whole model is contingent on the network profile. Regular VPC networks support firewall rules in hierarchical firewall policies, global network firewall policies, regional network firewall policies, and VPC firewall rules, but VPC networks that use certain network profiles restrict the firewall policies and rule attributes that you can use. Everything in this post is written about a regular VPC network, and an RoCE network is a different conversation with a different policy type.
Key Architecture Decisions
| Situation | Decision | Because |
|---|---|---|
| Migrating VPC firewall rules into a policy | Flip the network to BEFORE_CLASSIC_FIREWALL as a deliberate second step |
The default evaluates the old VPC rules first, so the policy is consulted only if they all delegate. |
| Recording where a policy sits in the order | Store the enforcement order with the network, not the policy | It is an attribute of the VPC network; one policy on two networks can sit in two places. |
| A control that must apply in every region | Global policy | It applies to all regions of the network, and one policy can serve several networks. |
| A control that differs by region | Regional policy | Per-project, per-region, and several can attach to one region of one network. |
| Layer 7 inspection rules | Put them in the global or hierarchical policy | apply_security_profile_group cannot be used in a regional policy. |
| Porting a rule that used source service accounts | Redesign it, do not translate it | Policy rules support service accounts as targets but not as sources. |
| Bulk-loading rules into a policy | Assign sparse, unique priorities first | Duplicate priorities are allowed in VPC rules and rejected in a policy. |
| A policy nearing its quota | Count FQDN objects and address group capacity, not rules | An FQDN object is 64 attributes; target secure tags are 0. |
| Separating authorship from activation | Grant Compute Security Admin and Compute Network Admin separately | Creating a policy and associating one require different roles. |
| Traffic allowed by no rule you can find | Look at the regional system policies | Google creates them, evaluates them before everything you control, and you cannot edit their rules. |
The one to look at today
For every VPC network in the project, read the networkFirewallPolicyEnforcementOrder attribute and write the answer down next to the network's name. If any network is on the default and also has a global or regional policy attached, you have a network where the policy is the second opinion rather than the first, and the VPC rule set is still the control plane. That is almost never what the person who built the policy intended, and it is invisible from the policy itself.
Closing Thought
The thing that stays with me from this one is that the firewall evaluation order is almost entirely fixed, and the single place it bends is controlled from the wrong object. Hierarchical policies first, system policies second, implied action last — none of that is configurable. The one adjustable joint sits between the VPC firewall rules and these policies, and the setting that adjusts it is a field on the network. A policy therefore cannot tell you when it runs, and two networks sharing a policy can disagree about it.
The second is that "policy" turned out to be a different language rather than a different container. Unique priorities, secure tags instead of network tags, no source service accounts, no Layer 7 action in the regional variant, and quota counted by attributes instead of rules. Each of those is defensible and the aggregate is a migration, not a refactor. Fourteen posts into the networking block, the recurring shape is the same one: the objects that look like generalisations of each other are the ones whose differences cost the most to discover late.
#75 turns to Firewall Insights and rule hygiene — which of the rules now spread across four policy types are actually being hit, and which are shadowed by something above them.
Official Google Cloud Reference
- Global network firewall policies
- Regional network firewall policies
- Firewall policies overview
- Firewall policy rule evaluation order
- Firewall policy rule components
- Cloud NGFW quotas and limits
- Hierarchical firewall policies
- Create global network firewall policies and rules
- Create regional network firewall policies and rules
- Cloud NGFW for RoCE VPC networks
- VPC firewall rules
Comments