# Firewall Rules

> zop.dev creates GCP firewall rules in 3 implicit places (project bootstrap, per Cloud SQL instance, and per Memorystore instance) and exposes direct CRUD via the firewall resource type for custom rules. GCP's default posture is deny ingress, allow egress, so every reachable port traces to an explicit rule.

Source: https://zop.dev/integrations/provision/gcp/firewall-rules
Updated: 2026-08-19

---

GCP firewall rules control which traffic reaches your network. zop.dev creates the rules its stacks need and exposes firewall management directly through the provisioner API.

## Rules from bootstrap, Cloud SQL, and Memorystore

Firewall rules created at project bootstrap, per Cloud SQL instance, and per Memorystore instance, plus direct firewall CRUD via the provisioner API's firewall resource type.

## Standard GCP rule fields passed straight through

```text
Standard GCP firewall rule fields passed through the provisioner's configs object.
```

## The firewall type is for the custom cases

Most firewall rules are created implicitly by other modules; the API resource type covers custom rules.

## Most rules were never written by hand

The firewall rules in a zop.dev project mostly arrive as side effects: the bootstrap module
creates the baseline set, and each Cloud SQL and Memorystore instance brings a rule admitting
its own traffic. The `firewall` resource type covers the remainder: the custom rule for an
unusual port, a partner's IP range, a debugging window. Knowing which rules are module-owned
matters for the same reason it does everywhere in this platform: hand-editing an implicit
rule invites the owning module to reassert it, while custom needs belong in explicitly
managed rules with names that say why they exist.

## Deny by default cuts both ways

GCP networks deny inbound and allow outbound unless told otherwise. The cost of that posture
is a predictable ritual: every new service reachable from somewhere new needs its rule, and
the symptom of forgetting is a connection timeout that looks exactly like an application
bug. The benefit is the audit property. The set of firewall rules is the complete answer to
"what can reach this network," with no implicit allowances to remember. A quarterly read of
the rule list is a real security review in a way that few other single artifacts provide.

## Free to hold, ordered by priority

Firewall rules cost nothing at any quantity, so the pressure to prune is clarity, not spend.
Evaluation order is by numeric priority, lower first, which is what makes rule interactions
reason-about-able: a specific allow can sit in front of a broad deny, and the effective
policy for any packet is the first match. The corollary is that stale rules are not harmless
clutter; a forgotten allow at aggressive priority silently wins over everything added after
it. Expired debugging rules are the ones to hunt.