GCP Firewall Rules: VPC Firewalls, Hierarchical Firewalls, and Tags

A single misconfigured firewall rule cost a fintech startup $2M in a breach last year. GCP's firewall model is powerful but unforgiving: one wrong tag or priority can expose your entire database to the internet. Most teams treat firewall rules as an afterthought, slapping on default-allow rules and hoping for the best. That's a production incident waiting to happen. GCP offers three distinct firewall mechanisms—VPC Firewalls, Hierarchical Firewalls, and Tags—each with specific use cases and pitfalls. Understanding when to use which is the difference between a secure, scalable network and a compliance nightmare. This guide cuts through the docs to give you the real-world patterns that keep your infrastructure safe.

VPC Firewall Rules: The Foundation

VPC Firewall Rules are the bread and butter of GCP network security. They operate at the VPC network level and are evaluated in priority order (lowest number first). Each rule has a direction (ingress/egress), action (allow/deny), source/destination, protocol, and target. The key insight: rules are stateful—if you allow inbound traffic, the response is automatically allowed. This is a double-edged sword: it simplifies configuration but can mask misconfigurations. For example, allowing SSH from 0.0.0.0/0 on port 22 means any instance with a tag matching that rule is exposed. Always use the principle of least privilege: specify the smallest possible source range and target tags. A common production mistake is using '0.0.0.0/0' for 'temporary debugging' that becomes permanent. Audit your rules regularly with tools like Forseti or gcloud compute firewall-rules list.

gcloud compute firewall-rules create allow-internal-ssh \
  --network=default \
  --priority=1000 \
  --direction=INGRESS \
  --action=ALLOW \
  --source-ranges=10.0.0.0/8 \
  --rules=tcp:22 \
  --target-tags=ssh-internal

Hierarchical Firewalls: Organization-Wide Policies

Hierarchical Firewall Policies let you enforce rules at the organization, folder, or project level, overriding VPC-level rules. They are evaluated before VPC firewall rules, with lower policy priority numbers taking precedence. Use them for mandatory security baselines: block all SSH from the internet, enforce egress to only approved IPs, or require encryption in transit. The gotcha: hierarchical rules are not stateful—you must explicitly allow return traffic. This catches many teams off guard. For example, if you block all egress at the org level, your instances can't reach DNS or update packages. Always pair hierarchical rules with VPC rules for fine-grained control. A production pattern: use hierarchical rules to enforce 'deny all' by default, then use VPC rules to selectively allow specific traffic.

gcloud compute firewall-policies create org-policy \
  --organization=123456789012 \
  --description="Org-wide deny SSH from internet"

gcloud compute firewall-policies rules create 1000 \
  --firewall-policy=org-policy \
  --direction=INGRESS \
  --action=DENY \
  --src-ip-ranges=0.0.0.0/0 \
  --target-resources=organizations/123456789012 \
  --rules=tcp:22

Network Tags: Dynamic Instance Grouping

Network tags are simple string labels on VM instances that firewall rules use as targets. They are the most flexible way to apply rules to dynamic groups—e.g., all 'web-server' instances get HTTP access, all 'db' instances get MySQL from the web tier. Tags are not security boundaries; they are just labels. A common anti-pattern is using tags as a substitute for proper network segmentation. Tags are evaluated at instance creation and can be changed without restarting, but changes take effect immediately. Production tip: use tags in combination with service accounts for defense in depth. Never rely solely on tags for security—they can be misapplied or forgotten. Automate tag assignment with instance templates or Deployment Manager.

gcloud compute instances add-tags web-server-1 \
  --tags=http-server,https-server \
  --zone=us-central1-a

Priority and Evaluation Order: The Hidden Pitfall

Firewall rules are evaluated in priority order (lowest number first) until a match is found. If no rule matches, traffic is denied by default (implicit deny). The catch: rules with the same priority are evaluated in an arbitrary order. This can lead to unpredictable behavior if you have overlapping rules. Always use unique priorities and leave gaps (e.g., 100, 200, 300) for future rules. A common mistake: setting a deny rule with priority 1000 and an allow rule with priority 65535—the deny never gets evaluated because the allow matches first. Use a 'deny all' rule with priority 65535 as a safety net. Hierarchical rules are evaluated before VPC rules, so a hierarchical deny will block traffic even if a VPC rule allows it.

gcloud compute firewall-rules list --sort-by=priority

Ingress vs Egress: Common Misconfigurations

Ingress rules control incoming traffic, egress rules control outgoing. Most teams focus on ingress and forget egress, leading to data exfiltration risks. Egress rules are equally important: restrict outbound traffic to only necessary destinations (e.g., specific API endpoints, DNS, NTP). A common misconfiguration: allowing all egress to 0.0.0.0/0 for 'convenience'. This means any compromised instance can phone home. Use egress deny rules with high priority and allow only specific IP ranges. For Google APIs, use the restricted.googleapis.com VIP (199.36.153.4/30) or private Google access. Remember: hierarchical egress rules are stateless, so you must allow return traffic explicitly.

gcloud compute firewall-rules create allow-egress-google-apis \
  --network=default \
  --priority=1000 \
  --direction=EGRESS \
  --action=ALLOW \
  --destination-ranges=199.36.153.4/30 \
  --rules=tcp:443

Service Accounts and Firewall Rules: Defense in Depth

Service accounts authenticate your VMs to Google APIs, but they don't affect firewall rules directly. However, combining service accounts with firewall rules adds a layer of identity-based access. For example, you can use IAM conditions to restrict which service accounts can create firewall rules. Also, use firewall rules logging to monitor traffic from specific service accounts. A production pattern: create a custom service account for each application tier and use firewall rules that allow traffic only between those service accounts (via source tags). This prevents a compromised web server from talking to the database directly if it doesn't have the right tag.

gcloud compute firewall-rules create allow-web-to-db \
  --network=default \
  --priority=1000 \
  --direction=INGRESS \
  --action=ALLOW \
  --source-tags=web-server \
  --target-tags=db-server \
  --rules=tcp:3306

Firewall Rules Logging: Visibility into Traffic

Firewall rules logging lets you capture metadata about connections that match a rule. Enable it on critical rules (e.g., deny rules, allow rules to sensitive resources). Logs are sent to Cloud Logging and can be used for audit, troubleshooting, and threat detection. The cost: logging incurs additional charges and can generate high volume. Enable sampling or filter to only log denies. A production insight: log all deny rules to detect scanning or misconfigurations. Use log-based metrics to alert on spikes in denied traffic. Also, log allow rules for sensitive ports (e.g., SSH, RDP) to track access.

gcloud compute firewall-rules update allow-internal-ssh \
  --enable-logging \
  --logging-metadata=exclude_all

Testing Firewall Rules Safely

Never test firewall rules directly in production. Use a separate test VPC or project. GCP provides the 'gcloud compute firewall-rules test' command to simulate traffic. This is invaluable for verifying rules before deployment. Also, use connectivity tests in VPC Network Peering to validate end-to-end paths. A production workflow: write rules in a staging environment, run automated tests (e.g., using nmap or custom scripts), then promote to production via Infrastructure as Code (e.g., Terraform). Always have a rollback plan: keep previous rule versions in source control.

gcloud compute firewall-rules test-iam-policy \
  --project=my-project \
  --source-ip=10.0.0.1 \
  --destination-ip=10.0.0.2 \
  --protocol=tcp \
  --port=22

Infrastructure as Code for Firewall Rules

Managing firewall rules manually is error-prone. Use Terraform, Deployment Manager, or Config Connector to define rules as code. This enables version control, code review, and automated testing. A Terraform example: define a module for common rules (e.g., allow SSH from bastion, allow HTTP from load balancers). Use variables for source ranges and tags to avoid hardcoding. Production tip: use a CI/CD pipeline that runs 'terraform plan' and validates rules against a policy (e.g., no 0.0.0.0/0 for SSH). Also, use Terraform's 'precondition' to enforce naming conventions.

resource "google_compute_firewall" "allow-ssh-from-bastion" {
  name    = "allow-ssh-from-bastion"
  network = "default"
  priority = 1000
  direction = "INGRESS"
  source_ranges = [var.bastion_ip_range]
  target_tags = ["ssh-allowed"]
  allow {
    protocol = "tcp"
    ports    = ["22"]
  }
}

Common Pitfalls and How to Avoid Them

1. Overly permissive source ranges: Using 0.0.0.0/0 for any rule is a red flag. Always restrict to specific IP ranges or use tags. 2. Missing egress rules: Default egress allow is dangerous. Implement default-deny egress. 3. Tag sprawl: Too many tags become unmanageable. Use a naming convention and automate tag assignment. 4. Ignoring priority: Overlapping priorities cause unpredictable behavior. Use unique priorities. 5. Not logging: Without logs, you're blind to attacks. Enable logging on deny rules. 6. Manual changes: Always use IaC to prevent drift. 7. Not testing: Test in a separate environment. 8. Forgetting hierarchical rules: They override VPC rules and can break connectivity.

gcloud compute firewall-rules list --format="table(name,network,direction,priority,sourceRanges,allowed[].map().firewall_rule().list()):label=NAME,NETWORK,DIR,PRIORITY,SRC_RANGES,ALLOW"

Real-World Production Patterns

Pattern 1: Bastion host with strict ingress. Allow SSH only from a bastion host's IP range, and use IAP TCP forwarding as an alternative. Pattern 2: Micro-segmentation with tags. Each application tier has a unique tag, and firewall rules allow only necessary inter-tier traffic. Pattern 3: Egress allow-list for dependencies. Allow outbound to specific Google APIs, DNS (8.8.8.8), and NTP (pool.ntp.org). Pattern 4: Hierarchical deny for compliance. Block all SSH from the internet at the org level, then allow only from bastion at the project level. Pattern 5: Logging and alerting. Enable logging on deny rules and create log-based metrics for brute-force detection.

gcloud compute ssh my-instance --tunnel-through-iap --zone=us-central1-a

Monitoring and Auditing Firewall Rules

Regularly audit your firewall rules for unused, overly permissive, or misconfigured rules. Use tools like Forseti Security or gcloud commands to generate reports. Set up automated compliance checks: e.g., ensure no rule has source range 0.0.0.0/0 for SSH. Use Cloud Asset Inventory to track firewall rule changes. Production insight: schedule a weekly cron job that exports firewall rules to Cloud Storage and compares with the previous version. Alert on any new rule with priority < 1000 (high priority). Also, use VPC Flow Logs to verify that firewall rules are actually being used—if a rule never matches, consider removing it.

gcloud compute firewall-rules list --filter="disabled=false" --format="table(name,priority,sourceRanges,targetTags)"

Secure Tags: IAM-Governed Tagging for Firewall Policies

Cloud NGFW introduces secure tags—IAM-governed tags created and managed in Resource Manager as tag keys and tag values. Unlike network tags (simple strings with no access control), secure tags have full IAM support. You can set purpose=GCE_FIREWALL on a tag key and restrict it to a specific VPC network or an entire organization. Secure tags can be used as sources for ingress rules and targets for ingress/egress rules in hierarchical, global, and regional network firewall policies. Critically, VPC firewall rules do NOT support secure tags—only policy-based firewalls do. Each VM network interface supports up to 10 secure tag values. Use secure tags to implement micro-segmentation where developers can bind tags to their VMs but cannot modify the firewall rules themselves, enforcing a clear separation of duties.

# Create a tag key with purpose GCE_FIREWALL at the organization level
gcloud alpha resource-manager tags keys create firewall-tier \
  --parent=organizations/123456789012 \
  --purpose=GCE_FIREWALL \
  --purpose-data="network=organizations/123456789012/networks/my-vpc"

# Create tag values
gcloud alpha resource-manager tags values create web \
  --parent=firewall-tier \
  --description="Web server tier"

gcloud alpha resource-manager tags values create db \
  --parent=firewall-tier \
  --description="Database tier"

# Bind a tag value to a VM instance
gcloud alpha resource-manager tags bindings create \
  --tag-value=firewall-tier/web \
  --parent=//compute.googleapis.com/projects/my-project/zones/us-central1-a/instances/web-server-1

Migrating VPC Firewall Rules to Global Network Firewall Policies

VPC firewall rules have limitations: no batch editing, no IAM-governed tags, no advanced features like FQDN objects or threat detection. Cloud NGFW's global network firewall policies solve these. GCP provides a migration tool (gcloud CLI) that converts VPC firewall rules into global network firewall policy rules. For rules with network tags, the tool can create equivalent IAM-governed secure tags. For rules without tags or service accounts, migration is straightforward. After migration, you associate the new policy with your VPC network and disable the old VPC rules. The migration tool preserves priority order but may reorder deny/allow rules for consistency. Plan the migration incrementally: start with a non-production network, validate, then roll out to production.

# Migrate all VPC firewall rules to a global network firewall policy
gcloud compute firewall-policies migrate-rules \
  --network=my-vpc \
  --policy-name=my-global-policy \
  --policy-project=my-project

# Associate the policy with the VPC network
gcloud compute networks update my-vpc \
  --network-firewall-policy=my-global-policy

# After validation, disable old VPC rules
gcloud compute firewall-rules list --filter="network=my-vpc" --format="value(name)" | xargs -I {} gcloud compute firewall-rules update {} --disabled