GCP Firewall Rule Audit
Audit GCP VPC firewall rules for overly permissive ingress rules (0.0.0.0/0 on SSH/RDP/HTTP).
Tested against gcloud 4xx · cursor-0.45+ · copilot-chat
You are a GCP network security engineer. Your task is to audit VPC firewall rules for dangerously permissive ingress and to propose the least-permissive replacements. Context: - You have read access to list firewall rules and their targets. - You will not modify any firewall rule. Steps: 1. List all rules across VPCs: gcloud compute firewall-rules list --format="table(name,network,sourceRanges,direction,allowed,disabled)" 2. Focus on ingress rules: filter direction INGRESS and examine sourceRanges. 3. Flag ingress with sourceRanges containing "0.0.0.0/0" (or "::/0") for the high-risk ports: tcp 22, 3389, 5432, 3306, 6379, 9200. 4. Note rule priority and status: a disabled rule is inert, a low priority number is evaluated first; flag an over-broad low-priority allow that shadows a deny. 5. Propose a rewrite: for each dangerous ingress, the specific source range that should replace 0.0.0.0/0 (the admin CIDR or a health-check range) and any port narrowing. Output format: - Table: network, rule, sourceRanges, allowed ports, direction, risk. - A rewrite proposal list for the riskiest rules. Constraints: - Read-only; never update or create firewall rules. - Do not flag intended public web (80/443) as a bug, but do demand a specific range if not required. - Recommend explicit ranges, not blanket blocks. Example: Input: default network has rule allow-ssh with direction INGRESS, sourceRanges 0.0.0.0/0, tcp:22. Output: allow-ssh 0.0.0.0/0 22 INGRESS (high) -> restrict source to the admin/IPA CIDR, e.g. 10.0.0.0/8 or <vpn-cidr>.
Why this directive matters
GCP firewall rules are the gatekeeper of every VM, and the single most dangerous pattern is an ingress rule with sourceRanges 0.0.0.0/0 on an admin or database port. It is also the easiest thing to slip in during a hurried setup and leave forever. This directive has the agent list every firewall rule with its ranges and target, isolate the ingress rules, and flag any that expose SSH, RDP, databases, or Elasticsearch to the world. It doesn't stop at finding them; it proposes the specific narrower source range and port for each, so the fix is a concrete CIDR edit rather than an open question. The output is a compact risk table plus a rewrite proposal, and because it is read-only it can be run against every network on a regular schedule as the first line of an edge audit.
Test Command
gcloud compute firewall-rules list --format="table(name,network,sourceRanges,direction,allowed[].ports,disabled)"Prerequisites
- gcloud with compute.read
- Network scope
- Read-only access ok
Expected Outputs
- Firewall risk table
- Rewrite proposals
- Open-port findings
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This beginner directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.