Firewall Rules
What does zop.dev create for Firewall Rules?
zop.dev creates GCP firewall rules only as side effects of other jobs: an allow-internal rule with each new network, a rule for ports 3306, 5432 and 6379 with each Cloud SQL or Memorystore job, one per VPC peering, and VM rules for VM pools. There is no separate firewall resource type. GCP denies ingress by default.
| Field | Value |
|---|---|
| Cloud | gcp |
GCP firewall rules control which traffic reaches your network. zop.dev creates the rules its stacks need as part of other provisioning jobs; there is no separate firewall resource to manage.
Rules from networks, datastores, peering, and VM pools
An <cluster>-allow-internal rule with each new network, a <name>-datastore-allow rule for each Cloud SQL or Memorystore job, an allow rule for each VPC peering, and firewall, health-check and IAP rules for each VM pool.
Fixed rule settings, no pass-through
Rule names, ports and source ranges are set by zop.dev; no custom firewall fields are accepted.Custom rules live outside zop.dev
Most firewall rules are created implicitly when other resources are provisioned; custom rules are created in your own GCP project tooling.
Most rules were never written by hand
The firewall rules in a zop.dev project arrive as side effects: each new network gets an allow-internal rule, and each Cloud SQL and Memorystore job brings a rule admitting datastore traffic. Anything else, such as the custom rule for an unusual port, a partner’s IP range or a debugging window, is yours to create outside zop.dev. Knowing which rules the platform owns matters for the same reason it does everywhere in this platform: hand-editing an implicit rule invites the platform 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.