VPC Service Controls

VPC Service Controls draws a perimeter around projects that limits which callers, from where, may reach their Google APIs, a guard against data leaving through the APIs themselves. The GCP Enterprise Baseline can build a perimeter around the four stage projects; it is off by default and always written as a dry run before it is enforced.

What it does

An organization has one access policy (Access Context Manager). A service perimeter in it lists projects and the restricted services whose APIs it protects: a call that crosses the perimeter boundary is refused unless an access level admits the caller (by network source, IP range or identity) or an ingress or egress rule allows the specific movement. A perimeter has an enforced status and an optional dry-run spec, whose would-be violations are only written to the audit logs. IAM still applies inside the perimeter; the perimeter adds a second, context-based check.

How BuiltForProd uses it

The organization-scoped vpc-sc unit (environments/core/security/global) reads two switches from network.hcl of the home region:

GCP/acme-gcp-platform-baseline/environments/core/network/us-west1/network.hcl (lines 22-23)

  enable_vpc_sc                     = false         # @optional: VPC Service Controls perimeter around the plat projects (free; dry-run first)
  enforce_vpc_sc                    = false         # @optional: enforce the perimeter (only after the dry-run violations are understood; units/vpc-sc)

With enable_vpc_sc = true the unit creates:

• The access policy of the organization, or uses an existing one named in access_policy_name, since an organization can have only one.
• The access level acme_platform_access, which admits requests from the hub VPC, its own subnets and the runner subnet, through Private Google Access, and from identities listed in access_members (users and service accounts only; access levels do not accept groups).
• The perimeter acme_plat around acme-plat-sandbox, -dev, -staging and -prod, restricting Cloud Storage, BigQuery, Secret Manager, Dataproc, Artifact Registry, Cloud Logging, Firestore and Memorystore.
• An egress rule pull-images-from-core-artifacts that lets anything inside the perimeter pull images from Artifact Registry in acme-core-artifacts.

The configuration is always written as the dry-run spec: violations land in the policy audit logs (cloudaudit.googleapis.com/policy), which the organization sink brings to the central log bucket, and nothing is blocked. enforce_vpc_sc = true writes the same configuration as the enforced status, once the dry-run violations are understood. VPC Service Controls has no charge.

CI under an enforced perimeter. GitHub-hosted runners call the APIs from outside the hub VPC. Before enforcing, the pipelines move to the Baseline's self-hosted runners, whose subnet is in the access level, through the repository variable RUNNER_LABELS, or their CI service accounts are listed in access_members.

VPC Service Controls protects the API layer; the Cloud NGFW firewall policies protect the network layer, and the organization policies the configuration.

Terms you will see

Term	Meaning
Access policy	The organization's single container for access levels and perimeters.
Service perimeter	acme_plat: the stage projects and the services it restricts.
Restricted service	An API whose calls the perimeter checks, such as storage.googleapis.com.
Access level	acme_platform_access: the network sources and identities admitted from outside.
Dry-run spec	The perimeter configuration that logs violations without enforcing them.
Egress rule	A named exception for calls from inside the perimeter to a resource outside it.

Where to read more

• GCP Enterprise Baseline overview for the optional security services and their switches.
• Cloud NGFW firewall policies for the network layer beneath the perimeter.
• Defense in depth for layering controls.