VPC Service Controls: Perimeter, Ingress/Egress Rules, and Dry-Run Mode

You locked down IAM, rotated keys, and enabled audit logs. Then a junior engineer ran bq extract to dump a production dataset to a public bucket. No credentials leaked — just a misconfigured job that cost you a compliance violation. VPC Service Controls exists to make that impossible. It's not a replacement for IAM; it's a safety net that blocks data exfiltration even when someone has valid permissions. Think of it as a blast shield around your GCP services: traffic can't cross the perimeter unless you explicitly allow it. This article covers the perimeter model, ingress/egress rules, and the critical dry-run mode that prevents you from breaking production on your first attempt.

The Perimeter Model: What It Protects and How

A VPC Service Controls perimeter is a logical boundary around a set of GCP projects and the managed services they use. Once a perimeter is defined, all requests to those services from outside the perimeter are denied by default — even if the caller has IAM permissions. The perimeter protects services like Cloud Storage, BigQuery, Bigtable, Cloud Spanner, and many others. It does not protect Compute Engine VMs, GKE clusters, or Cloud Functions directly (those are infrastructure, not managed services). The key insight: perimeters are project-based, not network-based. You add projects to a perimeter, and all protected services in those projects are subject to the policy. Access from inside the perimeter (e.g., a VM in the same project calling BigQuery) is allowed by default, but you can restrict it further with ingress/egress rules.

#!/bin/bash
# Create a basic VPC Service Controls perimeter
# Requires: gcloud, Organization Admin role

PERIMETER_NAME="prod-data-perimeter"
PROJECTS="projects/my-prod-project,projects/my-analytics-project"

# Create the perimeter (dry-run first!)
gcloud access-context-manager perimeters create $PERIMETER_NAME \
    --title="Production Data Perimeter" \
    --resources=$PROJECTS \
    --restricted-services="bigquery.googleapis.com,storage.googleapis.com" \
    --dry-run \
    --policy="organizations/123456789"

echo "Perimeter created in dry-run mode. Check logs before enabling."

Ingress Rules: Allowing Traffic Into the Perimeter

Ingress rules define who can access services inside the perimeter from outside. Without ingress rules, no external identity (user, service account, or network) can call any protected service. This is often too restrictive — you need to allow your developers, CI/CD systems, or on-premises applications to query BigQuery or write to Cloud Storage. An ingress rule specifies a source (identity or VPC network) and a destination (service, method, or operation). For example, you can allow a specific service account from a different project to read BigQuery datasets. Ingress rules are evaluated before the default deny, so they act as explicit exceptions. Important: ingress rules apply to the entire perimeter, not individual projects. If you need fine-grained control, consider multiple perimeters.

#!/bin/bash
# Add an ingress rule to allow a service account from another project
# to read BigQuery data inside the perimeter

PERIMETER_NAME="prod-data-perimeter"
POLICY_ID="123456789"

# Create ingress rule YAML
cat > ingress_rule.yaml <<EOF
- ingressFrom:
    identities:
    - serviceAccount:ci-runner@build-project.iam.gserviceaccount.com
    identityType: ANY_IDENTITY
  ingressTo:
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/my-prod-project
EOF

# Update perimeter with ingress rule
gcloud access-context-manager perimeters update $PERIMETER_NAME \
    --add-ingress-rules="ingress_rule.yaml" \
    --policy=$POLICY_ID

echo "Ingress rule added. Verify in dry-run logs."

Egress Rules: Controlling Data Leaving the Perimeter

Egress rules control what data can leave the perimeter. By default, services inside the perimeter can send data to any destination — that's a huge risk. An egress rule restricts outbound traffic to specific external services, networks, or identities. For example, you can allow BigQuery to export data only to a specific Cloud Storage bucket inside the same perimeter, or to a trusted on-premises network via a VPN. Egress rules are critical for preventing data exfiltration: even if an attacker gains access to a service inside the perimeter, they can't copy data to an external location unless an egress rule explicitly allows it. Like ingress rules, egress rules are evaluated before the default allow (for outbound traffic). They can be based on destination service, method, or resource.

#!/bin/bash
# Add an egress rule to restrict BigQuery exports to a specific bucket

PERIMETER_NAME="prod-data-perimeter"
POLICY_ID="123456789"

cat > egress_rule.yaml <<EOF
- egressFrom:
    identityType: ANY_IDENTITY
  egressTo:
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - method: google.cloud.bigquery.v2.JobService.InsertJob
    resources:
    - projects/my-prod-project
    externalResources:
    - projects/my-prod-project/buckets/export-bucket
EOF

gcloud access-context-manager perimeters update $PERIMETER_NAME \
    --add-egress-rules="egress_rule.yaml" \
    --policy=$POLICY_ID

echo "Egress rule added. Only exports to export-bucket are allowed."

Dry-Run Mode: Your Safety Net Before Enforcement

Dry-run mode is the most important feature of VPC Service Controls. When you create or update a perimeter in dry-run mode, the policy is evaluated but not enforced. All violations are logged to Cloud Logging under the VpcServiceControlsDryRun log type. This lets you see what would be blocked without actually breaking anything. You can monitor these logs for days or weeks to catch legitimate access patterns that would be denied. Once you're confident the policy is correct, you switch to enforcement mode. Never skip dry-run. In production, we've seen teams lose access to BigQuery for hours because they enabled a perimeter without testing. Dry-run gives you a safety net. Use it with a monitoring dashboard that alerts on dry-run violations.

#!/bin/bash
# Switch perimeter from dry-run to enforcement

PERIMETER_NAME="prod-data-perimeter"
POLICY_ID="123456789"

# First, check dry-run logs for violations
# (Assume you have a log sink set up)

gcloud logging read "logName=projects/my-prod-project/logs/VpcServiceControlsDryRun" \
    --limit=10 --format=json | jq '.[].jsonPayload.violationReason'

# If no unexpected violations, enable enforcement
gcloud access-context-manager perimeters update $PERIMETER_NAME \
    --no-dry-run \
    --policy=$POLICY_ID

echo "Perimeter now enforced. Monitor logs for real blocks."

Access Levels: Adding Context to Perimeter Rules

Access levels let you add context-aware conditions to ingress and egress rules. Instead of allowing all traffic from a service account, you can restrict it based on device policy, IP address, or time of day. Access levels are defined using the Access Context Manager API and can be reused across multiple perimeters. Common use cases: allow access only from corporate IP ranges, require that devices have endpoint verification enabled, or restrict access to business hours. Access levels are evaluated at request time, so they add latency but provide fine-grained security. They are especially useful for protecting sensitive data in regulated industries.

#!/bin/bash
# Create an access level that requires corporate IP range

POLICY_ID="123456789"
ACCESS_LEVEL_NAME="corporate_ip"

cat > access_level.yaml <<EOF
name: accessPolicies/$POLICY_ID/accessLevels/$ACCESS_LEVEL_NAME
title: Corporate IP Range
basic:
  conditions:
  - ipSubnetworks:
    - 203.0.113.0/24
    - 198.51.100.0/24
EOF

gcloud access-context-manager levels create $ACCESS_LEVEL_NAME \
    --title="Corporate IP Range" \
    --basic-level-spec="access_level.yaml" \
    --policy=$POLICY_ID

echo "Access level created. Use in ingress/egress rules."

Service Perimeters vs. Bridge Perimeters

VPC Service Controls offers two types of perimeters: service perimeters and bridge perimeters. Service perimeters are the standard type that restrict access to managed services. Bridge perimeters allow data exchange between two service perimeters without violating either perimeter's rules. For example, if you have a perimeter for production and one for staging, a bridge perimeter lets BigQuery in staging read data from production BigQuery datasets. Bridge perimeters are useful for data pipelines that cross environments, but they reduce isolation. Use them sparingly and only when necessary. Each bridge perimeter connects exactly two service perimeters and allows all traffic between them by default (though you can add restrictions).

#!/bin/bash
# Create a bridge perimeter between prod and staging

PROD_PERIMETER="prod-data-perimeter"
STAGING_PERIMETER="staging-data-perimeter"
POLICY_ID="123456789"

# Bridge perimeters are created as a separate type
gcloud access-context-manager perimeters create prod-staging-bridge \
    --title="Prod-Staging Bridge" \
    --type=bridge \
    --perimeter-type=bridge \
    --resources="projects/my-prod-project,projects/my-staging-project" \
    --restricted-services="bigquery.googleapis.com,storage.googleapis.com" \
    --policy=$POLICY_ID

echo "Bridge perimeter created. Traffic flows freely between prod and staging."

Monitoring and Alerting on Perimeter Violations

Once a perimeter is enforced, all violations are logged to Cloud Logging under the VpcServiceControls log type. You must set up monitoring and alerting to detect unauthorized access attempts. Common patterns: a service account from another project trying to read BigQuery, a user accessing Cloud Storage from an external IP, or a CI/CD pipeline that hasn't been updated with new ingress rules. Create a log-based metric for violations and set up an alert threshold (e.g., >10 violations in 5 minutes). Also monitor dry-run logs even after enforcement — they can reveal new access patterns that need rules. In production, we use a dashboard that shows violation trends by service and identity.

#!/bin/bash
# Create a log-based metric and alert for perimeter violations

# Create metric
gcloud logging metrics create perimeter-violations \
    --description="Count of VPC Service Controls violations" \
    --log-filter='logName="projects/my-prod-project/logs/VpcServiceControls"'

# Create alert policy (simplified via gcloud alpha)
gcloud alpha monitoring policies create \
    --display-name="Perimeter Violation Alert" \
    --condition-display-name="High violation rate" \
    --condition-filter='metric.type="logging.googleapis.com/user/perimeter-violations"' \
    --condition-threshold-value=10 \
    --condition-threshold-duration=300s \
    --notification-channels="projects/my-prod-project/notificationChannels/123"

echo "Alert created. You'll be notified when violations exceed 10 in 5 minutes."

Common Pitfalls and How to Avoid Them

1. Forgetting to add all projects: If a project uses a protected service but isn't in the perimeter, data can flow freely. Always audit your project list. 2. Overly permissive ingress rules: Using ANY_IDENTITY or broad VPC ranges can allow unintended access. Be specific. 3. Not testing dry-run long enough: A weekly batch job might only run on Sundays. Wait at least one full business cycle. 4. Ignoring egress rules: Default allow outbound is dangerous. Always restrict egress to known destinations. 5. Mixing perimeters with VPC firewall rules: VPC Service Controls is not a firewall. It doesn't block network-level traffic. Use VPC firewall rules for that. 6. Not documenting rules: When a violation occurs, you need to know why a rule exists. Document each ingress/egress rule with a reason and owner.

#!/bin/bash
# Audit perimeter projects and rules

PERIMETER_NAME="prod-data-perimeter"
POLICY_ID="123456789"

# List projects in perimeter
gcloud access-context-manager perimeters describe $PERIMETER_NAME \
    --policy=$POLICY_ID --format="json" | jq '.spec.resources'

# List ingress rules
gcloud access-context-manager perimeters describe $PERIMETER_NAME \
    --policy=$POLICY_ID --format="json" | jq '.spec.ingressRules'

# List egress rules
gcloud access-context-manager perimeters describe $PERIMETER_NAME \
    --policy=$POLICY_ID --format="json" | jq '.spec.egressRules'

echo "Audit complete. Verify projects and rules are correct."

Integrating with VPC Firewall Rules and IAM

VPC Service Controls works alongside VPC firewall rules and IAM, but they are not substitutes. IAM controls who can access a resource (authentication and authorization). VPC firewall rules control network traffic at the packet level (e.g., allow SSH from specific IPs). VPC Service Controls controls data exfiltration at the API level. For a defense-in-depth strategy, use all three. Example: IAM allows a service account to read BigQuery, VPC firewall allows traffic from the VM to the BigQuery API, and VPC Service Controls ensures the data stays within the perimeter. If any layer fails, the others still provide protection. Never rely on VPC Service Controls alone — it doesn't block network-level attacks or unauthorized IAM access.

#!/bin/bash
# Example of combining IAM, firewall, and VPC SC

# IAM: grant BigQuery read access to a service account
gcloud projects add-iam-policy-binding my-prod-project \
    --member="serviceAccount:data-reader@my-prod-project.iam.gserviceaccount.com" \
    --role="roles/bigquery.dataViewer"

# VPC firewall: allow outbound to BigQuery API (if using VPC)
gcloud compute firewall-rules create allow-bigquery-egress \
    --direction=EGRESS \
    --target-tags=data-vm \
    --destination-ranges=199.36.153.4/30 \
    --allow=tcp:443

# VPC SC: perimeter already configured (see previous examples)
echo "Defense-in-depth configured."

Advanced: Dynamic Perimeters with Conditions

You can make perimeters dynamic by using conditions in access levels. For example, allow access only if the request comes from a device that has endpoint verification enabled AND the user is in a specific group. This is useful for zero-trust architectures. Dynamic perimeters are configured using the Access Context Manager API with custom conditions. They can reference device attributes, user attributes, and environment attributes. However, dynamic conditions add latency and complexity. Use them only when static rules are insufficient. In production, we use dynamic perimeters for highly sensitive data (e.g., PII) where we require device posture checks.

#!/bin/bash
# Create a dynamic access level requiring endpoint verification

POLICY_ID="123456789"
ACCESS_LEVEL_NAME="device_verified"

cat > dynamic_level.yaml <<EOF
name: accessPolicies/$POLICY_ID/accessLevels/$ACCESS_LEVEL_NAME
title: Device Verified
basic:
  conditions:
  - devicePolicy:
      requireEndpointVerification: true
    members:
    - user:user@example.com
EOF

gcloud access-context-manager levels create $ACCESS_LEVEL_NAME \
    --title="Device Verified" \
    --basic-level-spec="dynamic_level.yaml" \
    --policy=$POLICY_ID

echo "Dynamic access level created. Only verified devices for user@example.com."

Troubleshooting Perimeter Issues

When something breaks, follow this checklist: 1. Check if the perimeter is in dry-run or enforcement mode. 2. Look at violation logs — they tell you exactly what was blocked and why. 3. Verify the request source: is it from inside or outside the perimeter? 4. Check ingress/egress rules: does an explicit rule allow or deny the request? 5. Review access levels: are conditions being met? 6. Test with a known-good identity (e.g., a service account that works). 7. Temporarily switch to dry-run to see if the issue is the perimeter. Common issues: missing ingress rule for a new service account, incorrect resource name in egress rule, or access level condition not satisfied. Use the gcloud command to describe the perimeter and verify rules.

#!/bin/bash
# Troubleshoot a blocked request

PERIMETER_NAME="prod-data-perimeter"
POLICY_ID="123456789"

# 1. Check perimeter mode
gcloud access-context-manager perimeters describe $PERIMETER_NAME \
    --policy=$POLICY_ID --format="json" | jq '.status | ."dryRun"'

# 2. View recent violations
gcloud logging read "logName=projects/my-prod-project/logs/VpcServiceControls" \
    --limit=5 --format=json | jq '.[].jsonPayload'

# 3. Test with a specific identity (simulate)
# Use the Access Context Manager test API (not shown for brevity)

echo "Troubleshooting steps completed."

Best Practices for Production Perimeters

1. Start with a single perimeter for your most sensitive data. Expand gradually. 2. Use dry-run for at least one week before enforcement. 3. Document every rule with a reason and owner. 4. Monitor violations and set up alerts. 5. Audit perimeters quarterly to remove stale rules. 6. Use access levels for context-aware access. 7. Avoid bridge perimeters unless absolutely necessary. 8. Test changes in a non-production environment first. 9. Automate perimeter creation with Infrastructure as Code (Terraform, Deployment Manager). 10. Train your team on how VPC Service Controls works — many incidents come from misunderstanding.

resource "google_access_context_manager_service_perimeter" "prod" {
  provider = google-beta
  parent   = "accessPolicies/123456789"
  name     = "prod-data-perimeter"
  title    = "Production Data Perimeter"
  status {
    resources = ["projects/my-prod-project", "projects/my-analytics-project"]
    restricted_services = ["bigquery.googleapis.com", "storage.googleapis.com"]
    vpc_accessible_services {
      enable_restriction = true
      allowed_services   = ["bigquery.googleapis.com"]
    }
  }
  use_explicit_dry_run_spec = true
}

resource "google_access_context_manager_service_perimeter_ingress_policy" "ci" {
  provider = google-beta
  perimeter = google_access_context_manager_service_perimeter.prod.name
  ingress_from {
    identity_type = "ANY_IDENTITY"
    identities    = ["serviceAccount:ci-runner@build-project.iam.gserviceaccount.com"]
  }
  ingress_to {
    operations {
      service_name = "bigquery.googleapis.com"
      method_selectors {
        method = "*"
      }
    }
    resources = ["projects/my-prod-project"]
  }
}

VPC Accessible Services: Controlling API Access Within the Perimeter

When you restrict a service (e.g., BigQuery) inside a perimeter, clients inside the VPC can still call its API. You can further control this using VPC Accessible Services settings on the perimeter. This configuration determines which Google APIs are accessible from within the perimeter—either the restricted VIP (restricted.googleapis.com) or the private VIP (private.googleapis.com). The restricted VIP only serves APIs that support VPC Service Controls, while the private VIP serves all Google APIs (including unsecured ones like consumer Gmail). For maximum security, use the restricted VIP. However, not all APIs are available on the restricted VIP. Before enabling, verify that the APIs your services depend on are supported. If they are not, you must use the private VIP, which weakens security because it allows access to non-protected services. Best practice: start with the restricted VIP, test thoroughly, and only fall back to private VIP if essential APIs are unavailable.

# Configure a perimeter to use restricted VIP
# Create perimeter with VPC accessible services
cat > perimeter_vpc.yaml <<EOF
- vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - bigquery.googleapis.com
    - storage.googleapis.com
    - bigtable.googleapis.com
EOF

gcloud access-context-manager perimeters update prod-data-perimeter \
    --policy=123456789 \
    --set-vpc-accessible-services="perimeter_vpc.yaml"

# Verify which services are on the restricted VIP
gcloud services list --available --filter="name~restricted.googleapis.com"

Propagation Delay and the 30-Minute Window

Changes to VPC Service Controls perimeters do not take effect instantly. After updating or creating a perimeter, there is a propagation delay of up to 30 minutes. During this window, the perimeter might block requests with Error 403: Request is prohibited by organization's policy. even if the configuration is correct. This is because the policy change must propagate across Google's infrastructure. This delay is especially dangerous when fixing a misconfigured perimeter: you make a change, but the fix takes up to 30 minutes to apply. Always plan maintenance windows accordingly. If you need to restore access urgently, the fastest way is to remove the affected project from the perimeter (which itself takes up to 30 minutes). For critical situations, have a break-glass procedure that involves temporarily disabling the perimeter entirely. Test propagation times in a non-production environment to set expectations.

# After updating a perimeter, wait and verify
# Step 1: Update perimeter
gcloud access-context-manager perimeters update prod-data-perimeter \
    --add-resources="projects/new-project" \
    --policy=123456789

# Step 2: Wait up to 30 minutes
# Step 3: Verify propagation
gcloud access-context-manager perimeters describe prod-data-perimeter \
    --policy=123456789 --format="json" | jq '.spec.resources'

# Monitor for 403 errors during propagation
gcloud logging read "protoPayload.status.code=7 AND protoPayload.status.message=~'VPC Service Controls'" \
    --limit=5 --format=json