implementing-gcp-vpc-firewall-rules
Implements and audits GCP VPC firewall rules using gcloud, covering auditing overly permissive rules, creating restrictive ingress/egress rules, hierarchical firewall policies, and monitoring rule effectiveness with VPC Flow Logs. Use when deploying GCP workloads needing network access controls, auditing firewall configs, or responding to Security Command Center findings; not for Cloud Armor or DNS-based filtering.
- License 许可
- Apache-2.0
- 最近更新
- 2026-08-31
- Stars
- ★ 3.6w
- Forks
- 4.4k
01 前言 Front Matter
- name
- implementing-gcp-vpc-firewall-rules
- tags
- [ "cloud-security", "gcp", "vpc", "firewall-rules", "network-security", "segmentation" ]
- author
- mahipal
- domain
- cybersecurity
- license
- Apache-2.0
- version
- 1.0
- nist_csf
- [ "PR.IR-01", "ID.AM-08", "GV.SC-06", "DE.CM-01" ]
- subdomain
- cloud-security
- description
- Implements and audits GCP VPC firewall rules using gcloud, covering auditing overly permissive rules, creating restrictive ingress/egress rules, hierarchical firewall policies, and monitoring rule effectiveness with VPC Flow Logs. Use when deploying GCP workloads needing network access controls, auditing firewall configs, or responding to Security Command Center findings; not for Cloud Armor or DNS-based filtering.
- mitre_attack
- [ "T1078.004", "T1530", "T1537", "T1580" ]
02 资源文件 9
- 参考文档animation-patterns.md4.1 KB
- 参考文档html-template.md12.2 KB
- 许可证LICENSE11.0 KB
- 参考文档references/api-reference.md2.3 KB
- 脚本scripts/agent.py7.4 KB
- 脚本scripts/export-pdf.sh12.0 KB
- 脚本scripts/extract-pptx.py2.8 KB
- 参考文档STYLE_PRESETS.md8.9 KB
- 其他viewport-base.css3.9 KB
03 SKILL.md 正文
Implementing GCP VPC Firewall Rules
When to Use
- When deploying new GCP workloads that require network-level access controls
- When auditing existing firewall configurations for overly permissive rules
- When implementing zero trust network segmentation within GCP VPC networks
- When responding to Security Command Center findings about open firewall rules
- When building hierarchical firewall policies across a GCP organization
Do not use for application-layer filtering (use Cloud Armor WAF), for DNS-based filtering (use Cloud DNS response policies), or for VPN/interconnect traffic filtering without understanding that VPC firewall rules apply to traffic within the VPC.
Prerequisites
- GCP project with Compute Engine API enabled
- IAM roles:
roles/compute.securityAdminfor firewall management,roles/compute.networkViewerfor auditing - Organization Admin role for hierarchical firewall policies
- gcloud CLI authenticated with appropriate permissions
- VPC Flow Logs enabled on target subnets for monitoring
Workflow
Step 1: Audit Existing Firewall Rules for Security Gaps
Enumerate all firewall rules and identify overly permissive configurations.
# List all firewall rules in the project
gcloud compute firewall-rules list \
--format="table(name, network, direction, priority, allowed[].map().firewall_rule().list():label=ALLOWED, sourceRanges, targetTags)"
# Find rules allowing all traffic from 0.0.0.0/0
gcloud compute firewall-rules list \
--filter="direction=INGRESS AND sourceRanges=0.0.0.0/0" \
--format="table(name, network, allowed, priority, targetTags)" \
--sort-by=priority
# Find rules allowing all protocols and ports
gcloud compute firewall-rules list \
--filter="direction=INGRESS AND allowed[].IPProtocol=all" \
--format="table(name, network, sourceRanges, targetTags)"
# Find rules with SSH (22) or RDP (3389) open to the internet
gcloud compute firewall-rules list \
--filter="direction=INGRESS AND sourceRanges=0.0.0.0/0 AND (allowed[].ports=22 OR allowed[].ports=3389)" \
--format="table(name, network, allowed, sourceRanges)"
# Check for disabled rules
gcloud compute firewall-rules list \
--filter="disabled=true" \
--format="table(name, network, direction)"
Step 2: Create Restrictive Ingress Firewall Rules
Implement least-privilege ingress rules using network tags and service accounts for targeting.
# Create rule allowing HTTPS from the internet to web servers only
gcloud compute firewall-rules create allow-https-web \
--network=production-vpc \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:443 \
--source-ranges=0.0.0.0/0 \
--target-tags=web-server \
--priority=1000 \
--description="Allow HTTPS to web servers from internet"
# Create rule allowing SSH only from bastion host subnet
gcloud compute firewall-rules create allow-ssh-bastion \
--network=production-vpc \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=10.0.1.0/24 \
--target-tags=ssh-allowed \
--priority=1000 \
--description="Allow SSH only from bastion subnet"
# Create rule allowing internal communication between app tiers
gcloud compute firewall-rules create allow-app-to-db \
--network=production-vpc \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:5432 \
--source-tags=app-server \
--target-tags=db-server \
--priority=1000 \
--description="Allow PostgreSQL from app tier to database tier"
# Create service-account-based rule (more secure than tags)
gcloud compute firewall-rules create allow-api-internal \
--network=production-vpc \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:8080 \
--source-service-accounts=api-client@project.iam.gserviceaccount.com \
--target-service-accounts=api-server@project.iam.gserviceaccount.com \
--priority=1000
Step 3: Implement Egress Restrictions
Configure egress firewall rules to control outbound traffic and prevent data exfiltration.
# Deny all egress by default (low priority)
gcloud compute firewall-rules create deny-all-egress \
--network=production-vpc \
--direction=EGRESS \
--action=DENY \
--rules=all \
--destination-ranges=0.0.0.0/0 \
--priority=65534 \
--description="Default deny all egress traffic"
# Allow egress to Google APIs via restricted VIP
gcloud compute firewall-rules create allow-google-apis \
--network=production-vpc \
--direction=EGRESS \
--action=ALLOW \
--rules=tcp:443 \
--destination-ranges=199.36.153.4/30 \
--priority=1000 \
--description="Allow HTTPS to Google APIs restricted VIP"
# Allow DNS resolution
gcloud compute firewall-rules create allow-dns-egress \
--network=production-vpc \
--direction=EGRESS \
--action=ALLOW \
--rules=udp:53,tcp:53 \
--destination-ranges=169.254.169.254/32,8.8.8.8/32,8.8.4.4/32 \
--priority=1000 \
--description="Allow DNS resolution to metadata and Google DNS"
# Allow egress to specific external services
gcloud compute firewall-rules create allow-external-apis \
--network=production-vpc \
--direction=EGRESS \
--action=ALLOW \
--rules=tcp:443 \
--destination-ranges=PARTNER_CIDR/32 \
--target-tags=api-client \
--priority=1000
Step 4: Deploy Hierarchical Firewall Policies
Create organization and folder-level firewall policies that apply across all projects.
# Create an organization-level firewall policy
gcloud compute firewall-policies create \
--organization=ORG_ID \
--short-name=org-security-policy \
--description="Organization-wide security firewall policy"
# Add rule to block known malicious IP ranges at org level
gcloud compute firewall-policies rules create 100 \
--firewall-policy=org-security-policy \
--organization=ORG_ID \
--direction=INGRESS \
--action=deny \
--src-ip-ranges=THREAT_INTEL_CIDR_1,THREAT_INTEL_CIDR_2 \
--layer4-configs=all \
--description="Block known malicious IPs organization-wide"
# Add rule to enforce HTTPS-only ingress at org level
gcloud compute firewall-policies rules create 200 \
--firewall-policy=org-security-policy \
--organization=ORG_ID \
--direction=INGRESS \
--action=allow \
--src-ip-ranges=0.0.0.0/0 \
--layer4-configs=tcp:443 \
--description="Allow only HTTPS from external sources"
# Associate policy with the organization
gcloud compute firewall-policies associations create \
--firewall-policy=org-security-policy \
--organization=ORG_ID
Step 5: Enable VPC Flow Logs for Monitoring
Configure VPC Flow Logs to monitor traffic patterns and validate firewall rule effectiveness.
# Enable flow logs on a subnet
gcloud compute networks subnets update production-subnet \
--region=us-central1 \
--enable-flow-logs \
--logging-aggregation-interval=interval-5-sec \
--logging-flow-sampling=1.0 \
--logging-metadata=include-all
# Query flow logs in Cloud Logging for denied traffic
gcloud logging read '
resource.type="gce_subnetwork"
AND jsonPayload.disposition="DENIED"
AND timestamp>="2026-02-22T00:00:00Z"
' --limit=50 --format=json
# Find traffic hitting overly permissive rules
gcloud logging read '
resource.type="gce_subnetwork"
AND jsonPayload.rule_details.reference:"/firewall-rules/default-allow-"
' --limit=100 --format="table(jsonPayload.connection.src_ip,jsonPayload.connection.dest_ip,jsonPayload.connection.dest_port)"
# Export flow logs to BigQuery for analysis
gcloud logging sinks create vpc-flow-bq \
bigquery.googleapis.com/projects/PROJECT/datasets/vpc_flow_logs \
--log-filter='resource.type="gce_subnetwork"'
Key Concepts
| Term | Definition |
|---|---|
| VPC Firewall Rule | Stateful network-level access control that allows or denies traffic to and from VM instances based on IP ranges, protocols, ports, and tags |
| Hierarchical Firewall Policy | Organization or folder-level firewall policy that is evaluated before VPC-level rules and applies across all child projects |
| Network Tag | Label applied to VM instances that determines which firewall rules apply, used for targeting ingress and egress rules |
| Service Account Firewall Rule | Firewall rule that targets instances based on their attached service account, providing more secure targeting than mutable network tags |
| VPC Flow Logs | Network telemetry captured at the subnet level that records traffic metadata for monitoring, forensics, and firewall rule validation |
| Implied Rules | Default GCP firewall rules that allow egress to all destinations and deny ingress from all sources, with lowest priority (65535) |
Tools & Systems
- gcloud compute firewall-rules: CLI commands for creating, listing, and managing VPC firewall rules in GCP
- Hierarchical Firewall Policies: Organization and folder-level policies enforcing security controls across all projects
- VPC Flow Logs: Subnet-level traffic logging for monitoring, troubleshooting, and validating firewall effectiveness
- Cloud Logging: Query engine for analyzing VPC Flow Logs and firewall rule hit counts
- Security Command Center: GCP-native security platform with findings for overly permissive firewall configurations
Common Scenarios
Scenario: Locking Down a Production VPC After Discovery of Overly Permissive Rules
Context: A security audit reveals that the production VPC has default-allow rules permitting SSH from 0.0.0.0/0 and unrestricted egress. SCC reports 14 firewall findings.
Approach:
- Enumerate all existing rules with
gcloud compute firewall-rules listand categorize by risk - Enable VPC Flow Logs on all subnets to capture baseline traffic patterns for 7 days
- Analyze flow logs to identify legitimate traffic that needs explicit allow rules
- Create targeted ingress rules for each application tier (web: 443, app: 8080, db: 5432)
- Replace the SSH-from-anywhere rule with SSH-from-bastion-subnet-only
- Implement default-deny egress and add explicit allow rules for required outbound destinations
- Delete the overly permissive default-allow rules after verifying applications function correctly
Pitfalls: Deleting firewall rules without understanding traffic patterns causes outages. Always enable flow logs and analyze traffic before removing rules. Network tags can be added by anyone with compute.instances.setTags permission, making them less secure than service-account-based targeting for critical rules.
Output Format
GCP VPC Firewall Audit Report
================================
Project: production-project
VPC Network: production-vpc
Audit Date: 2026-02-23
RULE INVENTORY:
Total firewall rules: 34
Ingress rules: 22
Egress rules: 12
Disabled rules: 3
CRITICAL FINDINGS:
[FW-001] SSH Open to Internet
Rule: default-allow-ssh
Source: 0.0.0.0/0 -> tcp:22
Target: All instances (no tags)
Priority: 65534
Remediation: Restrict to bastion subnet CIDR
[FW-002] No Egress Restrictions
Issue: Only implied allow-all-egress rule exists
Risk: No controls on outbound data exfiltration
Remediation: Add default-deny egress and explicit allow rules
REMEDIATION ACTIONS COMPLETED:
Rules deleted: 3 (overly permissive defaults)
Rules created: 8 (targeted allow rules)
Egress deny rule: Created at priority 65534
Flow logs enabled: 6 subnets
04 同仓库更多 Skills
verifying-build-provenance-with-slsa-sigstore
Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI/CD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.
validating-tpm-measured-boot-attestation
Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote/tpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware/kernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.
validating-backup-integrity-for-recovery
Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable/air-gapped backups for silent corruption or tampering.
triaging-windows-with-kape
Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment/triage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.
triaging-vulnerabilities-with-ssvc-framework
Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track/Track*/Attend/Act decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.
triaging-security-incident
Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM/EDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.