| name | gcp-firewall-rules |
| description | Review and harden Google Cloud VPC firewall rules for owned projects: 0.0.0.0/0 ingress, priority/order, target tags vs service accounts, hierarchical firewall policies, and shadow/redundant rules. Use when assessing GCP VPC allow/deny posture, open admin ports, over-broad CIDRs, or effective policy after org/folder policies — not for scanning or abusing third-party GCP networks.
|
GCP Firewall Rules (Authorized Hardening)
Assess and harden Google Cloud VPC firewall rules and hierarchical firewall
policies for org-owned or explicitly authorized GCP projects only.
Scope And Authorization
- In scope: VPC firewall rules, hierarchical firewall policies (org/folder),
network tags, service-account targets, and VPC layout in projects you own
or are contracted to harden; read-only exports; controlled changes with rollback.
- Out of scope: Off-scope scanning; opening prod management ports without
change control; foreign orgs/tenants; abusing discovered open hosts.
- Prefer config + VPC Flow Logs over live probes. Gate broad deny/priority
rewrites on shared prod behind a maintenance window and rollback plan.
- Redact internal CIDRs, bastion IPs, project numbers, and customer topology.
- GKE pod policy →
kubernetes-network-policy. Who can edit rules →
gcp-iam-basics. Cross-platform SG/ACL patterns → firewall-rule-review.
When To Use
- Reviewing VPC firewall rules (Console,
gcloud, Terraform
google_compute_firewall / hierarchical policy resources)
- 0.0.0.0/0 or
::/0 ingress to SSH, RDP, DB, Redis, or admin APIs
- Priority surprises, implied allow/deny, or rules that never hit
- Target tags vs service accounts vs “all instances”
- Org/folder hierarchical firewall overriding or shadowing VPC rules
- Cleaning shadow, duplicate, stale temporary, or undocumented broad allows
- Mentions: GCP firewall, VPC allow, network tags, target SA, hierarchical
firewall policy, effective firewall, open 22/3389 on 0.0.0.0/0
Do not use as primary for:
| Need | Skill instead |
|---|
| Multi-platform SG/NSG/host firewall review | firewall-rule-review |
| GCP IAM / who can edit firewalls | gcp-iam-basics |
| GKE NetworkPolicy / CNI isolation | kubernetes-network-policy |
| Secrets after a network hole | secrets-management-hygiene |
| Terraform module quality / tests | code-quality-standards, terraform-security-basics |
| Estate inventory first | recon-and-methodology |
Core Semantics (GCP-specific)
| Concept | Practice |
|---|
| Priority | Lower number = higher precedence (0–65535); first match wins per direction |
| Deny vs allow | Explicit deny can block lower-priority allows; document overrides |
| Targets | Prefer service accounts; tags are mutable/shared — avoid “all instances” on sensitive allows |
| Hierarchical | Org/folder policies + VPC rules → always model effective policy |
| Shadow rules | Higher-priority broader allow/deny can make later rules dead (false safety) |
| Sources | Prefer IAP, VPC, or known admin CIDR over 0.0.0.0/0 for management |
Anti-patterns: ingress 0.0.0.0/0 to 22/3389/3306/5432/6379/27017; full port
ranges to app tiers; tags reused across trust zones; temporary any/any without
owner/expiry; deny never reached because an earlier allow shadows it.
Workflow
1. Scope and inventory
Confirm project/org IDs, ownership, and change-freeze. Map VPCs, subnets, Shared
VPC host/service projects, trust zones, and critical assets (bastion, DB, GKE
nodes, internal LBs). Incomplete estate map → recon-and-methodology first.
2. Export VPC and hierarchical rules
gcloud config set project "$PROJECT_ID"
gcloud compute firewall-rules list --format=json
gcloud compute firewall-rules list \
--filter='direction=INGRESS AND sourceRanges:0.0.0.0/0' \
--format='table(name,priority,allowed,targetTags,targetServiceAccounts,network)'
Capture name, network, direction, action, priority, ranges, ports/protocols,
target tags/SAs, disabled flag, and description.
3. Priority, targets, shadows, egress
- Sort by network + priority; for critical 5-tuples (Internet→SSH, peer→DB),
find the first matching rule.
- Flag shadowed rules (dead after a higher-priority broader match).
- Prefer service-account targets for prod; review tag sprawl across zones.
- Reconcile hierarchical org/folder policy with VPC rules for effective path.
- Review egress from data/app tiers — not ingress-only.
4. Remediate and verify
Narrow management paths (IAP TCP, bastion, VPN/CIDR); remove unjustified
0.0.0.0/0 admin/data ports. Split over-broad rules; assign owner, ticket, and
expiry on exceptions. Delete disabled/stale/shadowed rules; encode via IaC
(terraform-security-basics + code-quality-standards). Re-export; use Flow
Logs or probes from approved sources only. Credential exposure →
secrets-management-hygiene. Rule mutators → gcp-iam-basics.
Routing
| Situation | Primary | Helper |
|---|
| GCP VPC / hierarchical firewall review | This skill | — |
| Generic multi-platform firewall methodology | firewall-rule-review | this skill (GCP semantics) |
| IAM on firewall/network admin | gcp-iam-basics | this skill (rule content) |
| GKE pod NetworkPolicy | kubernetes-network-policy | this skill (node VPC) |
| Secrets after open exposure | secrets-management-hygiene | this skill (close path) |
Terraform google_compute_firewall | terraform-security-basics | this skill + CQS |
| Missing project/VPC inventory | recon-and-methodology | this skill (deep rules) |
Output Checklist
Rules
- Owned or authorized GCP only — no foreign org/project assessment.
- Prove exposure with exports + priority analysis + logs, not disruptive
Internet-wide scans.
- State evaluation order and hierarchical vs VPC layers in findings.
- Undated unowned temporary
0.0.0.0/0 is still a finding.
- Keep immutable exports; change only through approved process and IaC.
