Firewall Rules and Network Tags

GCP firewall rules are stateful, attach to a VPC, and — unlike security groups — target VMs not by group membership but by network tag or service account. A rule on hatch-net-host that allows port 443 to instances tagged https-server opens that port on every VM carrying the tag, anywhere in the global VPC, and the return traffic is allowed automatically because the rule is stateful.

The mental shift for an AWS engineer is that the binding is the tag, not a group object the VM belongs to. A network tag is a free-form label any VM can carry, so the firewall surface is only as disciplined as your tag hygiene. Treat tags as a deliberate security control, not as casual metadata, and the model is clean; treat them carelessly and you open ports you never meant to.

Rules Live on the VPC, Target by Tag

A google_compute_firewall attaches to the network and selects targets with target_tags or target_service_accounts, matched against source_ranges or source_tags. A VM picks up a rule simply by carrying the matching network tag — the tag is the binding, not a membership in a group object. Add https-server to a VM's tags and it inherits every rule that targets that tag, across the whole global VPC.

Because the rule lives on the network and Hatch uses Shared VPC, every firewall rule belongs in hatch-net-host. A rule written in hatch-app-prod has no effect on the shared network, which is a common and silent source of "my allow rule isn't doing anything."

resource "google_compute_firewall" "allow_https" {
  project = "hatch-net-host"
  name    = "allow-https"
  network = google_compute_network.hatch.id

  direction     = "INGRESS"
  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["https-server"]   # any VM carrying this tag is exposed

  allow {
    protocol = "tcp"
    ports    = ["443"]
  }
}

The Implied Defaults

Every VPC ships with two implied rules: default-deny ingress and default-allow egress. Inbound is closed until you write an allow rule, which is the safe direction. Outbound is wide open until you write an explicit deny — nothing blocks egress until you do.

This catches AWS engineers who expect egress to be restricted by default. On GCP a fresh VM can reach the entire internet outbound, so if Hatch's security posture requires locking outbound down, you write explicit deny-egress rules. The implied default will not do it for you.

Priority

Every rule carries a priority from 0 to 65535, defaulting to 1000, and lower wins. A higher-priority deny — a smaller number — beats a lower-priority allow, which is how you carve a narrow exception into a broad rule. Set a deny at priority 100 over an allow at 1000 and the deny takes precedence for the traffic it matches.

Get the numbers backwards and the failure is silent. A broad low-priority allow at 1000 will shadow the narrow high-priority deny you intended if you accidentally gave the deny the larger number — the port stays open and nothing errors. Set priority explicitly on deny rules and document the intended ordering.

Stateful Return Traffic

Because rules are stateful, allowing inbound 443 automatically permits the response back out. You do not write a matching egress rule for the reply — the connection's return path is tracked and allowed. Writing a redundant outbound rule for return traffic does nothing and signals a stateless-ACL mental model that does not apply here.

This trips engineers coming from stateless network ACLs, where you pair an inbound rule with a matching outbound rule for the response. On GCP that pairing is wrong: one stateful rule covers the request and its reply. Only write an egress rule when you genuinely want to govern a new outbound connection, not to permit a response.

Hierarchical Firewall Policies

A google_compute_firewall_policy at the folder or org level applies rules above any individual VPC. The platform team can enforce "deny all RDP from the internet" across every project in the apps/ folder, and an app team cannot override it from inside their own project. This is governance that per-VPC rules cannot provide, because per-VPC rules live where the app team can edit them.

Use hierarchical policies for the non-negotiables — no public SSH, no public RDP — at the apps/ folder, and leave the workload-specific allows as per-VPC rules in hatch-net-host. The hierarchy enforces the floor; the VPC rules handle the specifics.