VPC Service Controls

Perimeters that stop credentialed data exfiltration.

VPC Service Controls is the GCP-specific control with no direct AWS analog, and it addresses a threat IAM alone cannot: a valid credential being used to copy data out of your managed services. If you run sensitive data in Cloud Storage or BigQuery, this is one of the highest-value controls you can deploy.

A perimeter around the data plane

VPC Service Controls draws a service perimeter around the APIs of a set of projects — Cloud Storage, BigQuery, and dozens more. Requests to those APIs are allowed only from inside the perimeter (or from explicitly permitted sources via access levels and ingress/egress rules). Even a principal with full IAM permission on a bucket cannot copy its data to a project outside the perimeter, because the perimeter blocks the cross-boundary API call regardless of the grant. It closes the "stolen token exfiltrates to attacker’s project" path that IAM cannot.

# An access level: only requests from the corporate IP range qualify.
# (defined in an access policy, referenced by the perimeter)
 
# The perimeter around the payments project's storage + bigquery APIs:
gcloud access-context-manager perimeters create payments-perimeter \
  --title="payments" --resources=projects/PAYMENTS_NUM \
  --restricted-services=storage.googleapis.com,bigquery.googleapis.com \
  --access-levels=corp_network
# A leaked token used from outside the corp network / perimeter cannot read the data.

Roll it out without an outage

A perimeter can break legitimate cross-project data flows, so never enforce blind. Start in dry-run mode, which logs every request the perimeter would block without actually blocking it; review those logs, add ingress/egress rules and access levels for the legitimate flows, and only then enforce. Combine the perimeter with access levels (device posture, IP, identity) so access is conditioned on context, not just credentials.