Module 2 · GCP Advanced — VPC-SC, WIF, Confidential Computing 🔒

This module covers advanced GCP security topics that come up in larger or regulated GCP deployments — VPC Service Controls, Workload Identity Federation, BeyondCorp Enterprise, Confidential Computing, and the assured-workload products for regulated industries. Material here assumes you’ve done Module 1 (GCP fundamentals) and are operating multi-project, multi-environment GCP at scale.

VPC Service Controls (VPC-SC) — the data exfiltration perimeter

VPC-SC creates a security perimeter around GCP services. Resources inside the perimeter (BigQuery datasets, GCS buckets, etc.) cannot be accessed by clients outside the perimeter — even with valid IAM credentials. This is the answer to “valid creds compromised → data exfiltrated.”

Perimeter components

• Perimeter: a boundary around projects + services
• Restricted services: which services are protected (e.g., bigquery.googleapis.com, storage.googleapis.com)
• Access levels: conditions for crossing the perimeter (specific IPs, identity, device, time-of-day)
• Ingress / Egress rules: explicit allowances for cross-perimeter traffic
• Bridge perimeters: connect projects across two perimeters

Practical pattern

PRODUCTION PERIMETER
  ├─ Projects: prod-app, prod-data
  ├─ Restricted services: bigquery, storage, cloudkms, pubsub
  ├─ Access level "corp-network": from corporate IP ranges + verified devices
  ├─ Ingress rule: from CI service accounts (specific) → bigquery (specific tables)
  └─ Egress rule: prod-app → ext-vendor-bucket (specific external GCS)

An attacker with a stolen prod service account key from outside the corp network cannot dump BigQuery — VPC-SC denies the call regardless of IAM permissions.

Operational reality

• VPC-SC is unforgiving — misconfiguration breaks production access
• Use Dry Run mode for weeks before enforcement
• “VPC accessible services” allow-list takes time to get right
• External services (third-party SaaS connecting to your BigQuery) need explicit ingress rules

Workload Identity Federation — keyless cross-cloud auth

Workload Identity Federation (WIF) lets external identities (AWS workloads, GitHub Actions, Azure AD, OIDC providers) authenticate to GCP without service account keys.

# GitHub Actions → GCP
# 1. Create a Workload Identity Pool in GCP
gcloud iam workload-identity-pools create github-pool \
  --location=global

# 2. Add OIDC provider for GitHub Actions
gcloud iam workload-identity-pools providers create-oidc github-actions \
  --workload-identity-pool=github-pool --location=global \
  --issuer-uri=https://token.actions.githubusercontent.com \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository"

# 3. Grant a service account to be impersonated by a specific repo
gcloud iam service-accounts add-iam-policy-binding ci-deployer@proj.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/projects/X/locations/global/workloadIdentityPools/github-pool/attribute.repository/myorg/myrepo"

# 4. In GitHub Actions YAML
# - uses: google-github-actions/auth@v2
#   with:
#     workload_identity_provider: 'projects/X/.../providers/github-actions'
#     service_account: 'ci-deployer@proj.iam.gserviceaccount.com'

No service account keys ever issued. CI deploy works. Compromise of GitHub repo doesn’t directly compromise GCP — attacker would need to push code that triggers a workflow.