Skip to content

Add VPC Service Controls evidence gates to gcp-review #1178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
KooZuKi wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add VPC Service Controls evidence gates to gcp-review #1178

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
100 changes: 95 additions & 5 deletions skills/cloud/gcp-review/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,16 @@ description: >
Foundation Benchmark v2.0.0. Auto-invoked when reviewing GCP infrastructure,
IAM bindings, VPC firewall rules, Cloud Audit Logs, or GCS bucket security.
Walks through all seven benchmark sections, evaluates each recommendation,
and produces a prioritized findings report with remediation guidance mapped
to specific CIS control IDs.
checks VPC Service Controls evidence for data-boundary claims, and produces a
prioritized findings report with remediation guidance mapped to specific CIS
control IDs.
tags: [cloud, gcp, cis-benchmark]
role: [cloud-security-engineer, security-engineer]
phase: [assess, operate]
frameworks: [CIS-GCP-v2.0.0]
difficulty: intermediate
time_estimate: "60-90min"
version: "1.0.0"
version: "1.0.1"
author: unitoneai
license: MIT
allowed-tools: Read, Grep, Glob
Expand All @@ -27,7 +28,7 @@ argument-hint: "[target-file-or-directory]"

This skill performs a structured security assessment of Google Cloud Platform environments against the **CIS Google Cloud Platform Foundation Benchmark v2.0.0**. The benchmark is organized into seven sections covering identity and access management, logging and monitoring, networking, virtual machines, storage, Cloud SQL, and BigQuery. Each recommendation is evaluated by inspecting infrastructure-as-code definitions (Terraform, Deployment Manager), gcloud CLI output, or configuration files available in the repository.

The CIS GCP Foundation Benchmark v2.0.0 provides prescriptive guidance for hardening GCP projects and organizations. This skill evaluates each applicable control and produces a findings report with CIS recommendation IDs, severity ratings, and actionable remediation steps.
The CIS GCP Foundation Benchmark v2.0.0 provides prescriptive guidance for hardening GCP projects and organizations. This skill evaluates each applicable control and produces a findings report with CIS recommendation IDs, severity ratings, and actionable remediation steps. When a review makes data-boundary claims for BigQuery, Cloud Storage, or service-to-service API access, CIS coverage is not the full boundary assessment; collect VPC Service Controls evidence separately and score it as posture evidence rather than as a CIS pass unless a specific benchmark control maps to it.

---

Expand Down Expand Up @@ -74,6 +75,8 @@ Use Glob to locate all GCP-related infrastructure definitions.
**/org-policies/**/*.json
**/org-policies/**/*.yaml
**/iam/**/*.json
**/access-context-manager/**/*.yaml
**/access-context-manager/**/*.json
```

Record all discovered files. If no GCP configurations are found, report that finding and halt.
Expand All @@ -88,7 +91,64 @@ For detailed CIS benchmark checklist items with specific Terraform patterns, gre

---

### Step 9: Compile Assessment Report
### Step 9: VPC Service Controls Evidence Review

Perform this step when the target includes Cloud Storage, BigQuery, sensitive data projects, service-to-service access boundaries, or any claim that VPC Service Controls protect data exfiltration paths. Do not treat the presence of a service perimeter as proof of enforcement.

**Evidence to locate:**

```
google_access_context_manager_service_perimeter
google_access_context_manager_service_perimeters
google_access_context_manager_access_level
accessPolicies/
servicePerimeters/
PERIMETER_TYPE_REGULAR
PERIMETER_TYPE_BRIDGE
use_explicit_dry_run_spec
useExplicitDryRunSpec
restricted_services
restrictedServices
ingress_policies
ingressPolicies
egress_policies
egressPolicies
```

For each perimeter, record the following fields:

- Access policy name or ID
- Perimeter name and title
- `perimeter_type` / `perimeterType`
- Enforced `status` resources and restricted services
- Dry-run `spec` resources and restricted services
- Whether `use_explicit_dry_run_spec` / `useExplicitDryRunSpec` is enabled
- Ingress rules, including identities, source projects, access levels, and allowed services
- Egress rules, including identities, destination projects, operations, and allowed services
- Access levels, including identity, device, IP range, and source-project conditions
- Shared VPC host projects and service projects included in or excluded from the perimeter
- Bridge membership and the data domains connected by the bridge
- Restricted/private VIP routing assumptions and any internet egress or Private Service Access paths that remain outside the perimeter

**Evaluation gates:**

- Separate enforced `status` from dry-run `spec`. Dry-run findings are advisory until promoted into enforced state.
- For `PERIMETER_TYPE_BRIDGE`, treat access as broad and bidirectional. Require business justification, project inventory, data classification for both sides, compensating IAM controls, and a rationale for why targeted ingress/egress rules are not safer.
- Do not score Terraform module inputs as sufficient evidence when they hide expanded `status`, `spec`, `perimeter_type`, ingress, or egress resources. Mark the VPC-SC portion **Not Evaluable** unless rendered configuration, Terraform plan output with expanded resources, or `gcloud access-context-manager perimeters describe` output is available.
- Check that Shared VPC service projects and host projects are covered consistently. A perimeter that lists only an application project can leave service-project or host-project access paths under-reviewed.
- When access levels are used, require the actual identity, device, IP range, and source-project conditions. Do not reduce access levels to a boolean.
- Call out Google-managed service and resource exceptions when a finding claims the perimeter blocks all service access paths.

**Severity guidance:**

- **Critical / High:** Sensitive data projects rely only on dry-run, bridge perimeters connect unrelated data domains, broad egress permits all projects or services, or Shared VPC service projects are outside the intended perimeter.
- **Medium:** Dry-run promotion evidence is missing, bridge justification is incomplete, access-level evidence is partial, or ingress/egress scope is broader than the stated data-flow requirement.
- **Low:** Enforcement appears present, but documentation, project inventory, or reviewer evidence is incomplete.
- **Informational:** VPC Service Controls are not in scope and no data-boundary claims are made.

---

### Step 10: Compile Assessment Report


Produce the final report using the structure defined in the Output Format section.
Expand All @@ -105,6 +165,10 @@ Produce the final report using the structure defined in the Output Format sectio
| **Low** | Hardening recommendation or defense-in-depth measure | OS Login not enabled, serial port access not explicitly disabled, BigQuery tables without CMEK |
| **Informational** | Best practice observation, no direct security impact | Default network still exists (non-production), naming conventions, documentation gaps |

### VPC Service Controls Severity Addendum

When VPC Service Controls are in scope, base severity on effective service-perimeter enforcement rather than perimeter existence. Dry-run-only protection for sensitive data is not an enforced control. Bridge perimeters and broad egress rules should be scored by the data domains and services they connect, not by the fact that they are declared in configuration.

---

## Output Format
Expand Down Expand Up @@ -150,6 +214,23 @@ Produce the final report using the structure defined in the Output Format sectio
- **Evidence:** <specific configuration or code snippet>
- **Remediation:** <specific fix with code example>

### VPC Service Controls Evidence

| Perimeter | Type | Enforced Resources/Services | Dry-run Resources/Services | Ingress/Egress Scope | Shared VPC Coverage | Status |
|-----------|------|-----------------------------|----------------------------|----------------------|---------------------|--------|
| <name> | Regular / Bridge | <status resources/services> | <spec resources/services> | <summary> | <host/service projects> | Pass / Fail / Not Evaluable |

#### [VPC-SC] <Finding Title>
- **Status:** Pass / Fail / Not Evaluable
- **Severity:** Critical / High / Medium / Low / Informational
- **Perimeter:** <access policy and perimeter name>
- **File:** <path to relevant config or export>
- **Line(s):** <line numbers if applicable>
- **Description:** <what was found>
- **Evidence:** <status/spec/perimeter_type/ingress/egress/access-level details>
- **Effective enforcement:** <enforced, dry-run only, bridge, or not evaluable>
- **Remediation:** <specific promotion, scoping, bridge replacement, or evidence collection step>

### Prioritized Remediation Plan

1. **[Critical]** CIS X.Y -- <action item>
Expand Down Expand Up @@ -194,6 +275,10 @@ Produce the final report using the structure defined in the Output Format sectio
4. **Cloud SQL authorized_networks vs. private IP.** CIS 6.5 flags `0.0.0.0/0` in authorized networks, but CIS 6.6 goes further and recommends disabling public IP entirely in favor of private networking.
5. **BigQuery dataset-level vs. table-level CMEK.** CIS 7.2 checks table-level encryption, while CIS 7.3 checks the dataset default. Both should be evaluated independently.
6. **Default compute service account identification.** The default SA follows the pattern `PROJECT_NUMBER-compute@developer.gserviceaccount.com`. Grep for this pattern, not just the string "default."
7. **Dry-run VPC Service Controls are not enforcement.** `spec` and `useExplicitDryRunSpec` show proposed behavior; `status` shows the active perimeter. Report the delta instead of treating both as equivalent.
8. **Perimeter bridges are intentionally broad.** `PERIMETER_TYPE_BRIDGE` can be valid, but it connects projects bidirectionally and should not be scored like narrow ingress/egress policies.
9. **Module inputs may hide real perimeter state.** If the review has only variables or wrapper-module inputs, mark VPC-SC claims Not Evaluable until rendered resources or `gcloud` exports show effective `status`, `spec`, type, ingress, and egress.
10. **Shared VPC membership can split the boundary.** Review both host and service projects so the assessment does not protect the workload project while leaving network or service-project paths outside the perimeter.

---

Expand All @@ -218,11 +303,16 @@ Produce the final report using the structure defined in the Output Format sectio
- Google Cloud IAM Documentation: https://cloud.google.com/iam/docs
- Google Cloud Audit Logs: https://cloud.google.com/logging/docs/audit
- Google Cloud VPC Documentation: https://cloud.google.com/vpc/docs
- Google Cloud VPC Service Controls Overview: https://cloud.google.com/vpc-service-controls/docs/overview
- Google Cloud VPC Service Controls Dry Run Mode: https://cloud.google.com/vpc-service-controls/docs/dry-run-mode
- Google Cloud VPC Service Controls Ingress and Egress Rules: https://cloud.google.com/vpc-service-controls/docs/ingress-egress-rules
- Google Cloud VPC Service Controls Perimeter Bridges: https://cloud.google.com/vpc-service-controls/docs/share-across-perimeters
- Google Cloud SQL Security: https://cloud.google.com/sql/docs/mysql/configure-ssl-instance
- Terraform Google Provider Documentation: https://registry.terraform.io/providers/hashicorp/google/latest/docs

---

## Changelog

- **1.0.1** -- Added VPC Service Controls evidence gates for enforced vs. dry-run state, perimeter bridge scope, Shared VPC coverage, ingress/egress/access-level evidence, and Not Evaluable handling when rendered perimeter state is unavailable.
- **1.0.0** -- Initial release. Full coverage of CIS Google Cloud Platform Foundation Benchmark v2.0.0 sections 1 through 7.