VPC Service Controls

VPC Service Controls (VPC SC) is a Google Cloud security feature that allows you to define a security perimeter around the resources of managed services (like BigQuery, Cloud Storage, Bigtable, etc.) to protect them from data exfiltration. Unlike IAM, which controls who can access a resource, VPC SC controls *where* access can come from and *where* data can go. It is designed to mitigate the risk of data exfiltration by unauthorized users or compromised applications, even if they have valid IAM permissions.

The primary use case is to prevent data from being copied from a managed service to an external, unauthorized destination. For example, a malicious insider with IAM access to a BigQuery dataset could export data to an external Cloud Storage bucket. VPC SC can block that export if the destination is outside the perimeter.

VPC SC operates by intercepting API calls to supported Google Cloud services. When a request is made to a service that is protected by a VPC SC perimeter, the service checks the request against the perimeter's configuration. The perimeter defines: - Service perimeter: The set of Google Cloud services that are protected (e.g., BigQuery, Cloud Storage, Bigtable). - Access levels: Conditions such as IP ranges, device policy, or identity that are required for access. - Ingress rules: Allow traffic from outside the perimeter to specific resources inside. - Egress rules: Allow traffic from inside the perimeter to specific resources outside.

If the request does not match the allowed access levels or violates ingress/egress rules, the request is denied with a 403 PERIMETER_DENIED error. The check happens at the API layer, not at the network layer, so it works even if the client is on the same VPC network.

Default behavior: When a perimeter is created in enforced mode, all API calls to protected services from outside the perimeter are denied unless explicitly allowed by ingress rules. All data movement from inside to outside is denied unless explicitly allowed by egress rules.

VPC SC is configured using the gcloud access-context-manager command-line tool or the Google Cloud Console. Here's a typical workflow:

gcloud access-context-manager levels create corp_network \
    --title="Corporate Network" \
    --basic-level-spec="conditions.yaml"

gcloud access-context-manager perimeters create my_perimeter \
    --title="My Perimeter" \
    --resources="projects/123456789" \
    --restricted-services="bigquery.googleapis.com,storage.googleapis.com" \
    --access-levels="corp_network" \
    --enable-restricted-services

gcloud access-context-manager perimeters update my_perimeter \
    --add-ingress-policies="ingress_policy.yaml"

gcloud access-context-manager perimeters update my_perimeter \
    --add-egress-policies="egress_policy.yaml"

To verify, you can check the status:

gcloud access-context-manager perimeters describe my_perimeter

As of the ACE exam, supported services include but are not limited to:

For the latest list, refer to the Google Cloud documentation.

Common errors: - 403 PERIMETER_DENIED: The request violated a perimeter rule. Check access levels, ingress, and egress rules. - 403 INVALID_ARGUMENT: Configuration error, such as invalid project ID or service name. - 403 ACCESS_LEVEL_VIOLATION: The requester does not meet the access level conditions.

To diagnose, use the gcloud access-context-manager perimeters describe command and review the audit logs. Enable dry-run mode first to test without enforcement.

When a request is made to a protected service: 1. The service receives the request and checks if the project is inside a VPC SC perimeter. 2. If yes, it checks the requester's access level (IP, device, etc.). 3. If the requester is outside the perimeter, it checks ingress rules. 4. If the request is to move data outside, it checks egress rules. 5. If any check fails, the request is denied with a 403 error. 6. If all checks pass, the request is allowed (subject to IAM).

This mechanism ensures that even with valid IAM permissions, data cannot be exfiltrated outside the perimeter without explicit rules.

Assume you want to allow BigQuery access only from the corporate IP range 203.0.113.0/24 and block all exports to external locations.

# conditions.yaml
- ipSubnetworks:
    - 203.0.113.0/24

gcloud access-context-manager perimeters create corp_bq_perimeter \
    --title="Corporate BigQuery Perimeter" \
    --resources="projects/my-project" \
    --restricted-services="bigquery.googleapis.com" \
    --access-levels="corp_network" \
    --enable-restricted-services

This configuration ensures that BigQuery can only be queried from the corporate network, and results cannot be exported anywhere unless explicitly allowed.

A large bank uses BigQuery and Cloud Storage to store customer transaction data. They need to ensure that data cannot be exfiltrated to unauthorized external systems, even by privileged users. They deploy VPC SC with a perimeter that includes all projects containing sensitive data. Access is restricted to the corporate network (IP range 10.0.0.0/8) via an access level. Egress rules are configured to allow data exports only to a specific Cloud Storage bucket in a separate project used for regulatory reporting. All other exports are blocked. In production, they run in dry run for two weeks to catch any legitimate access patterns that were missed. After enforcement, they monitor audit logs daily. A common issue is that developers often forget to add egress rules for legitimate data pipelines, causing failures. The solution is to use dry run and review logs before enforcement.

A healthcare organization uses Cloud Spanner and Cloud Storage for patient data. They allow researchers to access de-identified data from their personal devices, but only via a VPN. They create an access level that requires the user to be on the VPN IP range (203.0.113.0/24) and have a device certificate. They also allow egress to a specific Cloud Storage bucket for approved data exports. The perimeter includes the projects containing the Spanner instances and storage buckets. In production, they have to handle the case where researchers need to access data from a conference network; they temporarily add an ingress rule for that IP range. The main performance consideration is that VPC SC adds minimal latency because it checks at the API layer. Misconfiguration often occurs when egress rules are too permissive (e.g., allowing all Cloud Storage buckets), defeating the purpose.

A SaaS provider runs multiple customer environments in separate projects. They use VPC SC to isolate each customer's data. Each customer's project is in its own perimeter, with access restricted to the customer's IP range. Ingress rules allow the customer's support team to access specific services. Egress rules are very restrictive, only allowing data to flow to the customer's own storage buckets. They use Access Context Manager with custom attributes to identify each customer. A common mistake is creating perimeters that are too broad, accidentally including projects from different customers. They use organizational policies to enforce that all projects must be in a perimeter. Performance is not an issue, but managing many perimeters can become complex; they use infrastructure-as-code (Terraform) to manage configurations.