GCP VPC Network Security Audit

Cloud resource audit for Google Cloud Platform VPC Network architecture,
firewall posture, and connectivity. This skill evaluates provider-specific
GCP networking constructs — global VPC Network design, firewall rule
priority evaluation, hierarchical firewall policies, Cloud NAT egress
control, Cloud Interconnect VLAN attachments, Shared VPC host/service
project topology, and Cloud Router BGP sessions — not generic cloud
networking advice.

Scope: auto-mode versus custom-mode VPC Networks, subnet IP ranges,
firewall rules with target tags and service accounts, Cloud NAT port
allocation, Cloud Interconnect and Cloud VPN connectivity, Shared VPC
cross-project networking, Cloud Router dynamic routing. Out of scope:
Cloud CDN, Cloud Armor WAF, load balancer URL maps, Cloud DNS.
Reference references/cli-reference.md for read-only gcloud commands
and references/vpc-architecture.md for the GCP global VPC model and
firewall rule evaluation order.

When to Use

• - VPC Network architecture review — evaluating auto-mode versus custom-mode selection, subnet IP ranges, and Private Google Access configuration
• Post-migration audit — verifying firewall rules, Cloud NAT egress, and Cloud Router routes after workload migration
• Security assessment — identifying permissive firewall rules using target tags, missing hierarchical firewall policies, or disabled VPC Flow Logs
• Connectivity troubleshooting — diagnosing Cloud Interconnect VLAN attachment failures, Cloud VPN tunnel errors, or Shared VPC permission issues
• Compliance preparation — documenting VPC Network segmentation, firewall rule justification, and VPC Flow Log retention
• Cost optimization — identifying unused external IPs, over-provisioned Cloud NAT gateways, and idle Cloud Interconnect attachments

Prerequisites

• - gcloud CLI authenticated (gcloud auth list shows active account)
• IAM permissions — Viewer role on target project, or granular read: compute.networks.get, compute.firewalls.list, compute.routers.get, compute.interconnects.get, compute.subnetworks.list, compute.addresses.list. Shared VPC: Viewer on host and service projects. Hierarchical firewall policies: compute.firewallPolicies.get at org/folder level
• Target scope — project ID, organization ID (for hierarchical firewall policies), Shared VPC host project if applicable
• VPC Flow Logs — Step 1 checks subnet-level enablement. If no subnets have VPC Flow Logs, document as Critical

Procedure

Follow these six steps sequentially. Each builds on prior findings,
moving from inventory through security analysis to optimization.

Step 1: VPC Network Inventory and Design Assessment

Enumerate all VPC Networks in the target project and assess design.

CODEBLOCK0

For each VPC Network, evaluate:

• - Auto-mode vs custom-mode: Auto-mode VPC Networks create one subnet per region with predetermined /20 ranges from 10.128.0.0/9. Custom-mode requires explicit subnet creation. Production environments should use custom-mode. Auto-mode in production is a High finding.
• Global scope: GCP VPC Networks are global — subnets are regional but the network spans all regions. Unlike AWS/Azure, a single VPC Network hosts subnets in every region without peering. Verify subnet distribution matches workload regions.
• Subnet IP ranges: Primary ranges for VMs, secondary ranges for GKE Pod and Service CIDRs (alias IP ranges). Check for overlapping ranges and sufficient growth space.
• Private Google Access: Enables VMs without external IPs to reach Google APIs. Disabled Private Google Access on internal-only subnets is a Medium finding.
• VPC Flow Logs: Per-subnet enablement in GCP (not VPC-level like AWS). Subnets without VPC Flow Logs lack traffic visibility — flag as High for production.

Step 2: Firewall Rule Audit

Audit VPC Network firewall rules using GCP's priority-based evaluation and hierarchical firewall policies.

CODEBLOCK1GCP firewall rules evaluate by priority (0–65535, lowest = highest priority). First match wins.

• - Implied rules: Every VPC Network has implied deny-all-ingress and allow-all-egress at priority 65535. Not visible in gcloud compute firewall-rules list but active. Custom rules at 0–65534 override them.
• Priority conflicts: An allow at priority 1000 overrides a deny at 2000. Verify deny rules have lower priority numbers than conflicting allows.
• Target tags vs service accounts: Target tags are mutable labels — any project editor can change VM tags to bypass firewall rules. Service account targets are IAM-controlled and more secure. Flag tag-based rules on sensitive workloads as Medium.
• Source ranges: Rules permitting ingress from 0.0.0.0/0. SSH/RDP from 0.0.0.0/0 is Critical. Verify broad ranges are justified.
• Disabled rules: GCP firewall rules can be disabled without deletion. A disabled deny rule leaves a security gap.
• Default network rules: The default VPC Network includes pre-created rules allowing ICMP, SSH, RDP, and internal traffic. Audit these permissive rules.

Hierarchical firewall policies:

CODEBLOCK2

Hierarchical firewall policies apply at organization or folder level and evaluate before VPC Network firewall rules. A deny in a hierarchical policy blocks traffic regardless of VPC-level allows. A goto_next action delegates to VPC-level rules. Verify hierarchical policies enforce org-wide baselines (e.g., block SSH from internet).

Step 3: Cloud NAT and Egress Analysis

Audit Cloud NAT gateways for egress capacity, port allocation, and logging.

CODEBLOCK3
Cloud NAT provides outbound internet access for VMs without external IPs, configured on a Cloud Router.

• - IP allocation method: Automatic (GCP assigns IPs) or manual (reserved IPs). Manual provides predictable egress IPs for third-party allowlisting.
• Port allocation: Default 64 minimum ports per VM. Port exhaustion drops connections. Check minPortsPerVm/maxPortsPerVm. High-connection workloads need increased allocations. Enable Dynamic Port Allocation for bursty workloads.
• Endpoint-Independent Mapping: When enabled, Cloud NAT uses consistent IP:port mappings, improving protocol compatibility. Disabled by default.
• Cloud NAT logging: Verify logConfig.enable. Options: ERRORSONLY, TRANSLATIONSAND_ERRORS (recommended), ALL. Missing NAT logging reduces egress visibility.
• Subnet coverage: Cloud NAT applies to all subnets or specific subnets. Verify production subnets are covered.

Step 4: Connectivity Analysis

Evaluate hybrid and cross-project connectivity via Cloud Interconnect, Cloud VPN, and Shared VPC.

Cloud Interconnect:

CODEBLOCK4

• - VLAN attachment state: Verify state: ACTIVE and operationalStatus: OS_ACTIVE. UNPROVISIONED_ATTACHMENT means partner provisioning incomplete. OS_LACP_DOWN indicates link aggregation failure.
• BGP session health: Each VLAN attachment peers with a Cloud Router via BGP. UP is healthy, DOWN indicates ASN mismatch, authentication failure, or network issue. Verify primary and redundant sessions.
• MED values: Multi-Exit Discriminator influences route preference across multiple Cloud Interconnect attachments. Lower MED preferred. Verify values match active/standby design.
• Redundancy: Production requires connections in two edge availability domains. Single-connection topology is a High finding.

Cloud VPN:

CODEBLOCK5

• - Tunnel status: Should show status: ESTABLISHED. FIRST_HANDSHAKE indicates IKE negotiation in progress. NO_INCOMING_PACKETS suggests on-premises misconfiguration.
• HA VPN: High Availability VPN provides two tunnels for 99.99% SLA. Use HA VPN for production (Classic VPN offers no redundancy SLA).

Shared VPC:

CODEBLOCK6

• - Host/service project model: Shared VPC lets a host project share VPC Network subnets with service projects. Verify host project designation and service project associations.
• Subnet-level IAM: Shared VPC permissions granted per subnet via compute.networkUser role. Verify service accounts access only intended subnets.
• Private Google Access inheritance: Service projects inherit settings from host project subnets. Verify enablement.

Step 5: Cloud Router and Routing Validation

Audit Cloud Router configuration for route advertisements, BGP settings, and dynamic routing mode.

CODEBLOCK7

• - Dynamic routing mode: regional or global. Regional: Cloud Routers advertise/learn routes only within their region. Global: routes propagate across all regions. Multi-region workloads accessing on-premises via single-region Cloud Interconnect require global mode.
• Custom route advertisements: Default: advertise all subnets. Custom mode overrides — verify no subnets are accidentally excluded from advertisements.
• Graceful restart: Preserves forwarding during Cloud Router updates. Enable for production routers.
• AS path analysis: Review get-status learned routes and AS paths. Unexpected paths indicate route leaks or suboptimal selection.
• Route priorities: Custom routes use priority 0–65535 (default 1000). Lower preferred. Verify priorities create intended active/standby or ECMP behavior.
• Learned route limits: Cloud Router has per-region learned route limits. Approaching limits causes drops — check get-status for count versus limits.

Step 6: Report and Optimization

Compile findings and identify optimization opportunities.

CODEBLOCK8

• - Unused static IPs: Reserved external IPs not associated with resources incur charges. Release unused addresses.
• Disabled firewall rules: Create audit confusion. Delete or document justification.
• Over-permissive tag-based rules: Firewall rules targeting broad tags on high-privilege workloads should migrate to service account targets.
• IP address utilization: GCP reserves 4 addresses per subnet. Subnets with <10% available are exhaustion risks. Over-provisioned subnets waste space in Shared VPC.
• Cloud NAT consolidation: Multiple gateways per region unnecessary unless subnets need different configs.

Compile the findings report using the Report Template section.

Threshold Tables

Firewall Rule Severity

Finding	Severity	Rationale
Firewall rule allows SSH (22) from 0.0.0.0/0	Critical	Shell access from internet
Firewall rule allows RDP (3389) from 0.0.0.0/0

Critical | Remote desktop from internet | | Firewall rule allows all ports from 0.0.0.0/0 | Critical | No port restriction on ingress | | Target tag on sensitive workload instead of service account | High | Tags mutable by project editors | | Hierarchical firewall policy missing at org level | High | No organization-wide baseline | | VPC Flow Logs disabled on production subnet | High | No traffic visibility | | Firewall rule with priority 0 | High | Audit for broad scope | | Disabled firewall rule undocumented | Medium | Audit confusion risk | | Auto-mode VPC Network in production | Medium | Uncontrolled IP allocation | | Firewall rule with >20 source ranges | Medium | Excessive complexity |

Cloud Interconnect Health

Metric	Severity	Action
VLAN attachment state not ACTIVE	Critical	No traffic flow — engage provider
BGP session DOWN

High | Check ASN, authentication, link | | Single edge availability domain | High | No redundancy — add second | | Learned route count >80% limit | Medium | Approaching route capacity |

Cloud NAT Port Utilization

Available Ports (%)	Severity	Action
<10%	Critical	Connection drops — increase allocation
10–25%

High | Enable Dynamic Port Allocation | | 25–50% | Medium | Monitor trend | | >50% | Low | Healthy |

Decision Trees

Is This Firewall Rule Overly Permissive?

CODEBLOCK9

Is This VPC Network Design Following GCP Best Practices?

CODEBLOCK10

Report Template

CODEBLOCK11

Troubleshooting

VPC Flow Logs Not Enabled on Subnets

VPC Flow Logs in GCP are subnet-level, not VPC-level. Each subnet must
be individually enabled. Enabling is non-disruptive. Missing VPC Flow
Logs on production subnets is a High finding.

Firewall Rule Not Applied to Expected VMs

Verify the target: if using a target tag, confirm the tag is on the VM
(tags are case-sensitive). If using a service account target, verify the
VM runs with that account. Firewall rules with no target apply to all
VMs in the VPC Network.

Cloud Interconnect VLAN Attachment Not Active

Check state and operationalStatus. UNPROVISIONED_ATTACHMENT means
partner provisioning incomplete. OS_LACP_DOWN indicates Layer 2
failure. Verify Cloud Router BGP session has correct ASN and IP pair.

Shared VPC Service Project Cannot Deploy to Subnet

Verify the deploying service account has compute.networkUser on the
specific subnet in the host project. Subnet-level IAM is required even
if the service project is associated with the host project.

Cloud Router BGP Session Flapping

Check Cloud Logging with resource.type="gce_router". Common causes:
on-premises router exceeding learned route limit, authentication key
mismatch, or MTU issues on the Cloud Interconnect link. Enable graceful
restart to preserve forwarding during brief flaps.