Configuring Firewall Rules with Network Tags

Overview and What You Will Learn

In this lab, you will create a firewall rule targeting a specific network tag, then create two VMs - one carrying that tag, one without it - and confirm the rule applies only to the tagged VM, directly experiencing the tag-based targeting model.

Why This Matters in Production

An engineer coming from AWS or Azure creates a firewall rule expecting it to apply to every VM in a specific subnet, the way a security group or NSG might, then discovers a newly created VM without the matching tag is completely unaffected by that rule - silently, with no error to flag the mismatch, since the rule and the VM simply never had a targeting relationship in the first place.

Core Principles

Unlike clouds where security rules attach to a subnet or a VM's network interface directly, GCP firewall rules are defined at the VPC level and applied using network tags or Service Accounts on instances, rather than being tied to a specific subnet boundary.

Detailed Step-by-Step Practical Lab

1. Create a project, a VPC, and a subnet:

2. Create a firewall rule allowing HTTPS traffic, targeting only VMs tagged web-server:

3. Create a VM carrying the matching tag:

4. Create a second VM with no tag at all:

5. Confirm which firewall rules actually apply to each VM:

6. Attempt an HTTPS connection to each VM's internal IP from a third VM in the same subnet, and confirm the tagged VM accepts the connection while the untagged VM does not, since the firewall rule's target-tags condition never matches it.

7. As an alternative to tags, create a rule targeting a Service Account instead, which is often more reliable at scale since it's a real IAM identity rather than a manually-typed string:

8. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Creating a firewall rule and assuming it automatically applies to every VM in the target VPC or subnet. If the rule specifies --target-tags or --target-service-accounts, it only affects VMs carrying that exact tag or identity - a newly created VM without it gets none of that rule's protection or access, silently.

Tip

Prefer Service Account-based targeting over network tags for anything security-critical at scale. A Service Account is a real IAM identity that must be deliberately attached to a VM at creation time and shows up clearly in IAM audits, while a network tag is a freeform string that's easy to forget, misspell, or apply inconsistently across a growing fleet.

• Firewall rules also have a priority (lower numbers evaluated first) - the same concept as NSG or security group rule priority in Azure and AWS, letting a more specific deny rule override a broader allow rule evaluated later.
• Egress rules work the same tag-based way as ingress rules. A VM's outbound traffic is governed by rules matching its own tags or Service Account as the source, not the destination it's trying to reach.

Quick Reference & Troubleshooting Commands