Firewall Rules
What does zop.dev create for 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.
| Field | Value |
|---|---|
| Cloud | gcp |
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
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.