GCP VPC Service Controls: Preventing Data Exfiltration with Service Perimeters
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
A compromised service account in a GCP environment with only IAM controls can exfiltrate all BigQuery datasets to an attacker-controlled project in minutes. IAM permission to read BigQuery tables is also, by default, permission to copy those tables anywhere. VPC Service Controls closes this gap: it adds a perimeter layer where even an authorized identity cannot move data outside the protected boundary. The operational challenge is that VPC SC is complex to deploy correctly -- misconfigured perimeters break legitimate workflows, and the dry-run mode is non-negotiable before enforcement. This guide covers perimeter architecture, access level design, dry-run analysis, and the ingress/egress rules that handle legitimate exceptions without punching holes large enough to be exploited.
Design Your Perimeter Architecture Before Creating Any Perimeters
Perimeter design is the hardest part of VPC SC deployment. The wrong architecture creates either gaps that defeat the purpose or walls that break production.
Identify data that requires perimeter protection
Start with your most sensitive data assets: BigQuery datasets containing PII, financial records, or trade secrets; Cloud Storage buckets with compliance data. Map which GCP projects contain or produce this data. These projects are your perimeter core -- they must be inside the perimeter. Projects that only consume this data (read access) may or may not need to be in the same perimeter depending on data classification requirements.
Map service dependencies before restricting
For each project in the planned perimeter, inventory every Google API call it makes that crosses project boundaries. Cloud Audit Logs with data access logging enabled for 30 days gives you this map: `resource.type='bigquery_resource' protoPayload.authenticationInfo.principalEmail:<service-account>`. Any cross-project API call your workloads make today will be a perimeter violation when you enforce -- you need to map these before enforcing to build the correct ingress/egress rules.
Use a single perimeter for data projects, separate perimeters for consumption projects
A common architecture: one perimeter containing all data storage projects (BigQuery datasets, Cloud Storage buckets), and separate perimeters for each business unit or environment (dev, staging, prod) with access levels granting their service accounts permission to read from the data perimeter via ingress rules. This prevents the data perimeter from growing so large it becomes unmanageable, and allows different BU perimeters to have different access level requirements.
Exclude projects that cannot be perimetered
Some GCP services and project patterns are difficult to perimeter: projects using GKE Autopilot (which makes cross-project API calls for control plane operations), projects with direct VPC peering to on-premises networks, projects using Cloud Build (which needs to pull from multiple registries). Either keep these projects outside the perimeter and control their access via ingress/egress rules, or prepare for the engineering work of adapting their architecture to perimeter constraints.
Create Access Levels in Access Context Manager
Access levels define the conditions under which identities are granted perimeter access exceptions. Define these before creating the perimeter so you can reference them in ingress rules.
Create an IP-based access level for corporate egress IPs
For users and automation accessing perimetered services from on-premises or VPN: create an access level with your corporate IP CIDR ranges. In the GCP console, go to Access Context Manager, create an access level with Conditions type IP subnetworks, add your corporate egress IP ranges. Name it clearly: `corporate_network_access`. This level is used in ingress rules to allow console access to BigQuery by users on the corporate network without breaching the perimeter.
Create device-based access levels for end-user access
For users accessing perimetered services from laptops, create a device-based access level requiring: Endpoint Verification deployed and reporting, OS policy compliance (encrypted disk, recent OS version, screen lock enabled). Set the access level to require both IP range (corporate VPN or office) AND device compliance. This ensures that even if credentials are compromised, access from an unmanaged device is blocked at the VPC SC layer.
Create service account identity-based access levels
For specific service accounts that legitimately need cross-perimeter access (a data pipeline that reads from the data perimeter and writes results to a consumption project), create identity-based access levels that match those specific service account email addresses. Reference these in ingress rules on the data perimeter with scope limited to the specific APIs and resources needed -- storage.objects.get for specific bucket paths, not storage.* for all buckets.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Deploy in Dry-Run Mode and Analyze Violations Before Enforcing
Dry-run mode is mandatory. Never create a VPC SC perimeter in enforce mode on a production environment without first running dry-run for at minimum 1-2 weeks.
Create the perimeter in dry-run mode
In the GCP console, Security > VPC Service Controls, create a new service perimeter. Add the target projects, select the services to restrict (BigQuery, Cloud Storage, Cloud SQL at minimum), and set the mode to 'Dry-run.' The perimeter is now active but not enforcing -- all violations are logged to Cloud Audit Logs without blocking any API calls.
Query violation logs daily
Set up a scheduled Cloud Logging query to run daily and export violation counts by identity and API method: `logName:'vpc-service-controls' severity=WARNING`. Group results by `protoPayload.requestMetadata.callerIdentities[0].principalEmail` and `protoPayload.methodName`. The top violating identities and methods become your ingress/egress rule backlog. Resolve each legitimate violation with a rule; investigate unexpected violations for signs of misuse.
Build ingress/egress rules for each legitimate violation
For each service account or user identity appearing in violation logs with a legitimate use case, create an ingress rule: from = the violating identity with an appropriate access level, to = the perimeter project and restricted service, operations = only the specific API methods appearing in violations (not wildcards). Get approval from the data owner for each exception before adding the rule. The approval process is the security control -- VPC SC enforces it.
Switch to enforce mode after violation log is clean
When the dry-run violation log shows only unknown or illegitimate access patterns (not legitimate service accounts you have not yet added rules for), switch the perimeter to enforce mode. This is a one-way operation in terms of impact -- enforce mode immediately starts rejecting violations. Schedule the switch during low-traffic hours and monitor Cloud Audit Logs for unexpected Permission Denied errors for 2 hours after enforcement.
Monitor VPC SC Violations as an Ongoing Security Control
A VPC SC perimeter is not a set-and-forget control. Ongoing violation monitoring catches both legitimate gaps in your rule set and actual exfiltration attempts.
Alert on high-volume violation spikes
Create a Cloud Monitoring alerting policy that fires when VPC SC violation log rate exceeds 2x your baseline over a 15-minute window. A spike in violations can indicate: a misconfigured new service deployment generating unexpected API calls, a compromised service account attempting bulk data access, or a developer trying to access production data from a non-approved project. Each spike warrants investigation within 30 minutes.
Review perimeter membership quarterly
GCP project inventory changes as teams create and delete projects. Quarterly, review the perimeter's project list against your current project inventory to identify: (1) new projects containing sensitive data that should be added to the perimeter, (2) projects in the perimeter that were decommissioned and should be removed, (3) projects whose data classification changed (a project upgraded from internal to restricted should be added). VPC SC protects only what is explicitly included.
The bottom line
VPC Service Controls is the most effective GCP control for preventing insider threats and compromised credential exfiltration -- it enforces data movement policy at the API layer in ways IAM alone cannot. The complexity is in perimeter design and the dry-run analysis phase. Skipping dry-run mode in production environments causes immediate service disruptions that require emergency perimeter rule changes under pressure. Map your cross-project API call patterns before creating the perimeter, run dry-run for two weeks, build ingress/egress rules for every legitimate violation, then enforce. Treat ongoing violation monitoring as a detective control for exfiltration attempts.
Frequently asked questions
What is the difference between VPC Service Controls and VPC firewall rules?
VPC firewall rules control network packet flows at the virtual machine level -- they block or allow TCP/UDP traffic based on IP addresses, ports, and protocol. VPC Service Controls operate at the Google API layer and control which project context and identity context is permitted to call Google managed services (BigQuery, Cloud Storage APIs). A VPC firewall rule cannot prevent an authorized user from copying data from BigQuery to an external project using the BigQuery API -- VPC SC can. The two controls are complementary: firewall rules for network security, VPC SC for data plane security.
What is an access level in VPC Service Controls?
An access level is a named condition defined in Access Context Manager (ACM) that specifies which identities, device states, IP ranges, or regions are trusted for perimeter access. Examples: an IP-based access level allowing access only from your corporate egress IP range, a device-based level requiring managed devices with OS version and disk encryption verified by Endpoint Verification, or a combination requiring both IP range and device state. Access levels are attached to VPC SC ingress or egress rules to grant exceptions to perimeter enforcement.
What is a perimeter bridge and when do you need one?
A perimeter bridge creates a bidirectional communication path between two separate VPC SC perimeters, allowing resources in both perimeters to access each other's services without merging the perimeters. You need a bridge when different business units have their own perimeters and need to share specific data: for example, a data analytics perimeter needs read access to a finance perimeter's BigQuery dataset. Bridges are more controlled than merging perimeters -- they expose only the specific shared services rather than collapsing all perimeter boundaries.
How do you handle service accounts that need to access resources outside the perimeter?
Use ingress and egress rules with service account-based access levels. For a service account that must exfiltrate processed data to an external project (legitimate cross-perimeter access), create an egress rule specifying: from = the service account identity, to = the external project and specific GCS bucket or BigQuery dataset, operations = only the required API methods (storage.objects.create but not storage.objects.delete). This grants the minimum necessary exception without opening the perimeter broadly.
What happens when a VPC SC violation occurs?
In enforce mode, the API call returns a Permission Denied error to the caller with error reason VPCSC. In dry-run mode, the call succeeds but a violation is logged to Cloud Audit Logs with log name 'vpc-service-controls'. To analyze violations, query Cloud Logging: `resource.type='audited_resource' log_name:'vpc-service-controls'`. Each log entry includes the violating identity, the API method called, the target resource, and which perimeter policy was violated -- this is the data you need to tune ingress/egress rules before switching from dry-run to enforce.
Can VPC Service Controls protect Cloud Run and Cloud Functions?
Yes, but with important nuances. Cloud Run and Cloud Functions are supported VPC SC services, meaning API calls to manage them (deploying functions, creating services) are subject to perimeter policy. However, VPC SC does not inspect HTTP traffic to Cloud Run/Function endpoints -- it protects the control plane (management APIs) and the data plane access those functions make to other Google services (BigQuery, Cloud Storage). Place Cloud Run services inside a VPC SC perimeter to prevent them from making unauthorized API calls to services outside the perimeter.
How long does it take for VPC SC policy changes to take effect?
VPC SC policy changes propagate globally across Google infrastructure within 30 seconds to 2 minutes in most cases. For large organizations with many projects and perimeters, propagation can take up to 5 minutes. During propagation, some API calls may see inconsistent enforcement. Always make VPC SC policy changes during low-traffic periods and monitor Cloud Audit Logs for unexpected violation patterns in the 5 minutes following any policy change.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.