VPC Service Controls

Introduction to VPC Service Controls

For a Professional Cloud Architect, IAM is not enough to prevent data exfiltration. While IAM controls "Who" can access data, it cannot prevent a malicious insider or a compromised identity from moving that data to an external, non-authorized GCP project.

VPC Service Controls (VPC SC) provides a "security perimeter" around your Google-managed services (like BigQuery, GCS, and Cloud SQL) to keep your data inside your trusted environment.

Plain-Language Explanation: VPC Service Controls

VPC Service Controls is like the high-security walls and checkpoints of a military base.

Analogy 1 — The Military Base (Service Perimeter)

IAM is like having a "Base ID Card" (Identity) that lets you into the "Research Lab" (Service). However, nothing stops you from putting a secret document in your pocket and driving out the front gate to a rival's house. VPC SC is the High Concrete Wall around the entire base. Even if you have the ID card to see the document, the wall prevents you from taking that document outside the base.

Analogy 2 — The Secure Tunnel (Bridge Perimeter)

Imagine two separate military bases (Project A and Project B) that need to share secrets. You don't want to tear down the walls of both bases. Instead, you build a Secure Tunnel (Bridge Perimeter) between them. This allows authorized people to carry documents between Base A and Base B, but they still can't take them anywhere else.

Analogy 3 — The Guard at the Gate (Access Levels)

Access Context Manager is the Guard at the Gate. The guard doesn't just look at your ID card; they also check: "Are you driving a base-authorized vehicle?" or "Are you coming from a trusted GPS location?" If you try to enter from a suspicious location, the guard blocks you, even if your ID card is valid.

Core Components of VPC SC

1. Service Perimeter

A logical boundary that encloses a set of projects and Google-managed services.

• Restricted Services: You choose which services (e.g., BigQuery, GCS) are protected by the perimeter.
• Effect: Communication between protected services and anything outside the perimeter is blocked by default.

2. Access Levels (Access Context Manager)

Define conditions for accessing resources from outside the perimeter.

• Criteria: IP Address, Device Type (e.g., must be encrypted), User Identity, and more.
• Use Case: Allow employees on the corporate VPN to access BigQuery even though they are technically "outside" the perimeter.

3. Perimeter Bridge

Connects two or more perimeters.

• Requirement: Projects in both perimeters must trust each other.
• Use Case: Allowing a production project in one perimeter to read data from a data-lake project in another perimeter.

Ingress and Egress Rules Deep Dive

While Access Levels handle identity- and device-based exceptions, ingress and egress rules offer attribute-level control over which API calls cross the perimeter. Each rule is a tuple of from {sources, identities, identityType} and to {operations, resources}.

Ingress Rules — letting external callers in

• from.identities: specific service accounts (e.g., a Dataflow worker SA in a non-perimeter project) allowed to invoke services inside the perimeter.
• from.sources.accessLevel: combines an Access Level (corporate IP/device) with the rule, so only callers matching both the identity AND the context get in.
• to.operations: scope to specific methods such as storage.googleapis.com / google.storage.objects.get — read access yes, list/write no.

Egress Rules — letting perimeter workloads reach out

• to.resources: target a specific external project number (projects/123456789), not just a service. This is how you allow a BigQuery job in the perimeter to export to gs://partner-bucket without opening the whole storage.googleapis.com API.
• to.externalResources: lets services egress to non-Google endpoints exposed via Service Directory or PSC consumer endpoints.
• Identity scoping: combine egressFrom.identities with egressTo.operations to allow only a single Composer SA to write to one external GCS bucket — minimal blast radius.

VPC SC Dry-run Mode

VPC SC is powerful and can easily break your applications if misconfigured. Every new perimeter or rule change should start in dry-run.

How dry-run works

• Each perimeter has an enforced config and a dry-run config. Both evaluate every request in parallel.
• The dry-run config writes simulated denies to policyDenied logs with dryRun: true, but the request is still allowed by the enforced config.
• Use Log Explorer with the filter protoPayload.metadata.dryRun="true" and group by resource.labels.service to find every legitimate workflow that would break.

Promotion workflow

1. Apply the new config as dry-run via gcloud access-context-manager perimeters dry-run create / update.
2. Run for 7-30 days covering monthly batch jobs and quarterly close cycles.
3. Promote with gcloud access-context-manager perimeters dry-run enforce <perimeter> once dry-run logs are clean.

Private Google Access and the Restricted VIP

To communicate with Google APIs from within a VPC without using public IP addresses, you use Private Google Access (PGA). With VPC SC, PGA has two flavors that matter for the exam.

private.googleapis.com — 199.36.153.8/30

• Default PGA VIP. Resolves to all Google APIs, including services NOT supported by VPC SC (think compute.googleapis.com operations, oslogin).
• Use when the VM is inside a non-perimeter project and needs broad Google API access without public egress.

restricted.googleapis.com — 199.36.153.4/30

• The restricted VIP used with VPC SC. Resolves only to services that VPC SC supports (BigQuery, GCS, Pub/Sub, Spanner, etc.).
• Required pattern: a DNS managed zone in the VPC for *.googleapis.com pointing CNAME → restricted.googleapis.com, plus a route for 199.36.153.4/30 to default-internet-gateway.
• Combined with a deny-all egress firewall rule to 0.0.0.0/0, this guarantees a VM in the perimeter physically cannot reach any non-VPC-SC Google service or the public internet.

Troubleshooting Denied Requests

When VPC SC blocks a request, the client receives an HTTP 403 with an error of type vpcServiceControlsUniqueIdentifier (the unique ID). The denial is also written to two log streams.

Where to look

• Cloud Audit Logs → policyDenied: under protoPayload.status.details, look for violations[].type (e.g., VPC_SERVICE_CONTROLS) and the vpcServiceControlsUniqueId field. This ID is the primary correlator.
• VPC SC Troubleshooter (Console): paste the unique ID and it reverse-resolves the blocked principal, target service, target resource, and the perimeter/rule that fired.

Common violation types

• NO_MATCHING_ACCESS_LEVEL — caller is external to the perimeter and no ingress rule or Access Level matched.
• RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER — cross-perimeter read where neither a bridge nor ingress/egress rule covers it.
• SERVICE_NOT_ALLOWED_FROM_VPC — workload is calling a restricted service the perimeter does not permit at all.

Investigation query

resource.type="audited_resource"
protoPayload.status.code=7
protoPayload.metadata.violationReason="RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"

Group by protoPayload.authenticationInfo.principalEmail to find the offending workload.

Cross-Perimeter Sharing via Bridges

Bridges solve the "two strong perimeters need to exchange data" problem without weakening either one.

Bridge mechanics

• A bridge perimeter is a list of projects whose VPC-SC-protected services are mutually accessible to each other. It is not a perimeter you put workloads in.
• A project must already belong to a regular perimeter; the bridge is overlaid on top.
• Bridges are bidirectional and symmetric — every member can read/write every other member.

When to choose bridge vs ingress/egress

• Bridge: a tight group of projects (data lake + multiple analytics projects) where everything-to-everything is the desired behavior.
• Ingress/egress rules: asymmetric or narrow access (analytics perimeter reads from data-lake perimeter but data-lake should not read back). Modern best practice favors ingress/egress over bridges because of finer granularity.

Limits to remember

• A project can join at most 10 bridges.
• Bridge membership does NOT bypass Access Levels — if perimeter A requires corporate_vpn access level for external callers, calls coming via the bridge from perimeter B still need to satisfy any ingress rule that references that condition.

VPC SC for BigQuery, GCS, and Pub/Sub

The three services that dominate PCA exam scenarios behave slightly differently inside a perimeter.

BigQuery

• Cross-project query (e.g., project-A.dataset.table reading from a table in project-B) requires both projects in the same perimeter OR an ingress rule on project B's perimeter listing project A's service account.
• Authorized views / authorized datasets still respect VPC SC: the dataset's project must be reachable from the caller's perimeter.
• bq load from a GCS bucket outside the perimeter requires an egress rule to storage.googleapis.com scoped to that bucket's project.

Cloud Storage

• gsutil cp from a perimeter VM to an external bucket is blocked even if the IAM is open — VPC SC overrides IAM.
• Signed URLs generated inside the perimeter still enforce VPC SC when the bucket is restricted; the signature lets IAM through, but the API call itself must originate from an allowed source.
• storage.googleapis.com and storage.cloud.google.com are both restricted by the perimeter — exam distractors often claim only the API hostname is covered, which is wrong.

Pub/Sub

• Cross-project subscriptions where publisher and subscriber sit in different perimeters require ingress rules referencing pubsub.googleapis.com / google.pubsub.v1.Subscriber.Pull.
• Push subscriptions to an HTTPS endpoint outside Google land are blocked unless the destination is exempted via egress — most teams switch to pull subscriptions or a perimeter-internal Cloud Run target.

Layering PSC and VPC SC

Private Service Connect (PSC) and VPC SC are complementary, not redundant.

What each one does

• PSC for Google APIs: consumer-side endpoint with a private IP inside your VPC that targets all-apis or a specific API bundle. Solves the "we cannot use the 199.36.153.4/30 range because it collides with on-prem" problem.
• VPC SC: API-level boundary that prevents data flowing to projects outside the perimeter, regardless of network path.

Combined pattern

1. Create a PSC endpoint with target all-apis (or vpc-sc bundle) and a private IP in the VPC.
2. Put the project hosting the endpoint inside a service perimeter.
3. DNS-redirect *.googleapis.com to the PSC endpoint instead of the restricted VIP.
4. The endpoint forwards to the GFE, where VPC SC re-evaluates the call against the perimeter — so a compromised workload still cannot exfiltrate to a project outside the perimeter even though it has private connectivity.

PSC for backends

PSC also lets a perimeter project consume a producer service (e.g., a third-party SaaS or another tenant's internal service) over private IP. The producer's consumer-accept list scopes which projects can connect, while VPC SC ensures the data destination is bounded.

FAQ — VPC Service Controls

Q1. How is VPC SC different from a VPC Firewall?

VPC Firewalls control traffic between VMs (Layer 3/4). VPC SC controls access to Google-managed services (APIs) like BigQuery and GCS. They work at different layers of the stack.

Q2. Can I have a project in more than one Service Perimeter?

No. A project can only belong to one Service Perimeter at a time. To share data between projects in different perimeters, you must use a Bridge or Ingress/Egress rules.

Q3. Does VPC SC affect performance?

No. VPC SC is implemented at the Google API frontend (GFE) and does not add measurable latency to your requests.

Q4. What happens to existing data when I enable VPC SC?

Nothing happens to the data itself, but access to that data will be immediately restricted based on the perimeter rules. This is why Dry-run mode is essential.

Q5. Can VPC SC prevent data exfiltration via the internet?

Yes. By restricting which IP addresses (Access Levels) can reach your data and blocking all egress to external projects, VPC SC effectively prevents data from being leaked to the public internet or unauthorized accounts.

Final Architect Tip

For the PCA exam, think of VPC SC as the "Exfiltration Killer." If a scenario mentions "malicious insiders," "data leakage between projects," or "securing SaaS/API services," VPC SC is the intended answer. Be prepared to explain the difference between IAM (Identity-based) and VPC SC (Boundary-based) security. Also, remember that Access Context Manager is the tool used to define the specific "Access Levels" (IP, Device, etc.) for the perimeter.