Business Challenge
The last two posts covered what a rule says and what it does when nothing says anything. This one covers how a rule finds the instances it applies to, which turns out to be the most consequential choice in the whole firewall model — because targets identify the network interfaces of instances to which the firewall rule applies, and the two ways of naming them have different security properties.
Google does not present this as a matter of taste. The guidance is unambiguous: if you need strict control over how firewall rules are applied to VMs, use target service accounts and source service accounts instead of target network tags and source network tags. The reason is a permission boundary, and once you see it the recommendation stops being advice and becomes arithmetic.
If they target by network tag, they are controlled by whoever can edit a VM. A network tag is an arbitrary attribute, and one or more network tags can be associated with an instance by any Identity and Access Management (IAM) principal who has permission to edit it. The consequence is stated plainly: IAM principals who can edit an instance can change its network tags, which could change the set of applicable firewall rules for that instance. And the bar is not high — IAM principals with the Compute Engine Instance Admin role to a project have this permission.
Correct approach
Separate the two questions: who may write firewall rules, and who may decide which rules apply to an instance. With tags, the second group is everyone with instance-edit on the project, no matter how tightly you hold compute.firewalls.update. Where that matters, target by service account, because you control access to the service account by controlling the grant of the Service Account User role for other IAM principals.
Not in the same rule, and the restriction reaches further than the target field. You cannot mix and match service accounts and network tags in any firewall rule, and specifically you cannot use target service accounts and target network tags together in any firewall rule (ingress or egress). Your target choice then constrains the sources: with target network tags, source service accounts are invalid, as is a combination of source IP ranges and source service accounts; with a target service account, source network tags are invalid, as is a combination of source IP ranges and source network tags.
Correct approachPick one scheme per network and apply it consistently, because a half-migrated estate cannot express a rule that spans both. IP ranges are the only source type compatible with either target choice, so a migration between the two schemes runs through CIDR-based rules rather than directly.
They cost you operational flexibility and headroom. Changing a service account for an instance requires stopping and restarting it, while adding or removing network tags can be done while the instance is running. And you can name far fewer of them: 70 target network tags per rule against 10 target service accounts, 30 source network tags against 10 source service accounts, with every one of those limits marked this limit cannot be increased.
Correct approachDecide per environment rather than globally. Where instance identity is stable and the rules are security-critical, service accounts are right and the restart requirement is a one-time cost at build. Where you need to move workloads between policy groups without downtime — a staged rollout, an incident response that quarantines a host — tags are the only option that does it live, and the honest reading is that you are trading strictness for that.
Architecture
There are three ways to pick targets, and the first is the one people forget is a choice at all.
| Target specification | Behaviour |
|---|---|
| Omitted | When you omit a target specification, the firewall rule applies to all instances in the VPC network |
| Target network tags | Applies if the instances have a network tag that matches at least one of the firewall rule's target network tags |
| Target service accounts | Applies if the instances use a service account that matches at least one of the firewall rule's target service accounts |
Both named forms match on "at least one", so they are unions rather than intersections — an instance with any one of the listed tags is in scope. And the target parameter is broader than plain VMs: it identifies the network interfaces of the Compute Engine instances, including GKE nodes and App Engine flexible environment instances.
The three axes, side by side
| Axis | Network tag | Service account |
|---|---|---|
| What it is | An arbitrary attribute | An identity associated with an instance |
| Who can change which rules apply | Anyone who can edit the instance — Compute Engine Instance Admin on the project suffices | Whoever holds Service Account User on that service account |
| How many per instance | Several | Only one service account can be associated with an instance |
| Change while running | Yes — adding or removing network tags can be done while the instance is running | No — changing a service account for an instance requires stopping and restarting it |
| Per-rule ceiling, targets | 70 | 10 |
| Per-rule ceiling, ingress sources | 30 | 10 |
Tags carry seven times the target capacity and three times the source capacity, and none of those ceilings can be raised. For a large estate that is a real constraint on service-account-based designs: ten target service accounts per rule means a policy covering more than ten identity groups needs more rules, not a longer list.
An instance can carry several tags, so tag-based targeting lets one VM belong to many overlapping policy groups at once — web, pci, canary — and you compose policy by stacking rules. A service account is singular, so service-account targeting forces each instance into exactly one group. That is the same property that makes it strict: there is no way to add a second identity to a VM to pick up an extra rule, which is precisely what makes a tag easy to abuse and a service account hard to.
Sources, and the one type compatible with both
For ingress rules the source can be an address range, instances identified by network tags, instances identified by service account, or either of those combined with addresses — instances identified by range of IPv4 or IPv6 address and by network tag, or identified by range of IPv4 or IPv6 addresses and by service account. Left unspecified, the default source is any IPv4 address ( 0.0.0.0/0 ), which is worth remembering given #71's finding that the default network ships rules with exactly that source.
Address ranges are the only source type legal under both target schemes. That makes them the bridge for any migration: to move a rule set from tags to service accounts you re-express the identity-based sources as CIDRs, change the targets, then narrow the sources back down — because there is no intermediate state in which a single rule names a tag on one side and a service account on the other.
Why This Architecture Holds Up
Two sentences in the operational-considerations list limit the scope of each scheme, and both land on the same gap.
For tags: if you identify instances by network tag, the firewall rule applies to the primary internal IP address of the instance. Not the alias ranges, not the IPv6 addresses — the primary internal address. So a tag-based rule describing what a workload may do does not describe what its alias-range services may do.
For service accounts in Kubernetes: service account firewall rules apply to the GKE node, not the GKE Pod. Since #64 established that GKE Pods get their addresses from alias IP ranges, that is the same boundary again from the other direction. A service-account rule governs the node's own traffic, and Pod traffic is riding addresses the rule does not speak about.
This is now three distinct rules about alias IP ranges, each in a different document. #64: alias ranges are excluded when you specify firewall sources by tag or service account. #69: an alias IP range is the wrong resource type for a static route next hop and the route is disregarded. #72: a tag-based firewall rule applies to the primary internal address, and service-account rules stop at the GKE node. The consistent reading is that alias addresses are first-class for routing and addressing and second-class for every mechanism that identifies a workload. If your security model depends on constraining Pod or service traffic, none of these three mechanisms is the right instrument — which is the gap network policy and service mesh exist to fill.
Who may change what
The permission split is worth stating because it is the other half of the security argument. Writing rules needs compute.firewalls.create and the Compute Security Admin role ( roles/compute.securityAdmin ); the same role covers delete and update. Reading them needs only the Compute Network Viewer role ( roles/compute.networkViewer ).
So the platform already separates seeing the policy from changing it. The point of this post is that tag-based targeting quietly reunites them: a principal with no firewall permission at all, holding only instance-edit, can change which rules apply to a machine. The policy document stays untouched and its effect changes. Service-account targeting closes that by making the equivalent action require Service Account User on a specific service account — and, as #71 noted about the default network, by making the change loud rather than silent, since it needs a restart.
One detail completes the picture: for an IAM principal to start an instance by using a service account, that principal must have the Service Account User role to at least use that service account and appropriate permissions to create instances. Both permissions, not either. Placing a workload into a firewall policy group therefore requires a grant that somebody deliberately made.
A note on secure tags, which are a different thing
The limits page lists a parallel set of numbers that are easy to misread: maximum number of source secure tags per ingress firewall policy rule 256 and maximum number of target secure tags per firewall policy rule 256. Those are secure tags in firewall policy rules, not network tags in VPC firewall rules — a different mechanism with its own IAM model and far more headroom. They belong to the policies material in #73 and #74, and the only thing to carry from them today is that the capacity constraint above applies to VPC firewall rules specifically.
Key Architecture Decisions
| Situation | Decision | Because |
|---|---|---|
| Rules enforcing a security boundary | Target service accounts | Google's own guidance for strict control, and tags are editable by anyone with instance-edit. |
| Workloads that must move between policy groups without downtime | Network tags, knowingly | Changing a service account requires a stop and restart. |
| More than ten identity groups in one rule | Split the rule, or use tags | Ten target service accounts per rule, and the limit cannot be increased. |
| A VM that needs to belong to several overlapping policies | Tags | Only one service account can be associated with an instance. |
| Any single rule | One scheme only | Tags and service accounts cannot be mixed, and the target choice invalidates the other scheme's sources. |
| Migrating from tags to service accounts | Route it through IP-range sources | Address ranges are the only source type legal under both target schemes. |
| Constraining Pod or alias-range traffic | Neither — use network policy or a mesh | Tag rules apply to the primary internal address; service account rules stop at the GKE node. |
The one to look at today
Count the principals in each project that hold a role including compute.instances.setTags or the Compute Engine Instance Admin role, then compare that number with the count holding compute.firewalls.update. If the first is larger — and it almost always is — then the difference is the set of people who can change which firewall rules apply to a machine without being able to change a firewall rule. That is the number your tag-based rules are actually trusting, and it is usually nobody's idea of the security boundary.
Closing Thought
This is the first thing in the networking block that is primarily an IAM decision wearing a networking label. The firewall mechanics are identical either way: same priorities, same directions, same evaluation order, same statefulness. What differs is which permission governs membership of the set a rule applies to — and that question belongs to the thirty posts before this block rather than to the eleven in it.
Which also makes the trade-off unusually clean to state. Tags are mutable by whoever can edit the instance, which is what makes them operationally pleasant and what makes them weak. Service accounts move membership into IAM, which is what makes them strict and what makes them awkward: one per instance, a restart to change, a tenth of the headroom. There is no option that is strict and flexible, and reading the page carefully makes it clear Google is not pretending otherwise — it names the preference for strict control and then lists, in the next paragraph, exactly what that preference costs.
#73 moves up a level to the policies that apply across networks: hierarchical firewall policies, where the organization and folder nodes get a say before any VPC rule is consulted.
Comments