gcp-networking-audit

GCP VPC Network audit covering global VPC design, firewall rule priority evaluation with hierarchical policies, Cloud NAT egress analysis, Cloud Interconnect and Shared VPC connectivity, Cloud Router BGP validation, and resource optimization using read-only gcloud CLI commands.

# 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.

```
gcloud compute networks list --project <project-id>
gcloud compute networks describe <network-name> --project <project-id>
gcloud compute networks subnets list --network <network-name>
```

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.

```
gcloud compute firewall-rules list --filter="network:<network-name>"
gcloud compute firewall-rules describe <rule-name>
```GCP 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:**

```
gcloud compute firewall-policies list --organization <org-id>
gcloud compute firewall-policies describe <policy-name>
gcloud compute firewall-policies rules list --firewall-policy <policy-name>
```

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.

```
gcloud compute routers nats list --router <router-name> --region <region>
gcloud compute routers nats describe <nat-name> --router <router-name> --region <region>
```
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: ERRORS_ONLY, TRANSLATIONS_AND_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:**

```
gcloud compute interconnects list
gcloud compute interconnects describe <interconnect-name>
gcloud compute interconnects attachments list --region <region>
gcloud compute interconnects attachments describe <attachment-name> --region <region>
```

- **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. Verif