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

Last updated: April 29, 2026

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 [email protected] \
  --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: '[email protected]'

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.

BeyondCorp Enterprise — context-aware access

Google’s zero-trust access platform. Replaces VPN with context-aware authentication for internal apps:

• User identity (verified)
• Device posture (managed, encrypted, patched)
• Geographic context
• Sign-in risk

Implemented via Identity-Aware Proxy at the edge of internal HTTPS apps. Apps don’t need their own auth — IAP handles it; user identity propagated as headers.

Confidential Computing

Confidential VMs use AMD SEV (or AMD SEV-SNP for newer) to encrypt VM memory. Key implication: the cloud provider (Google) cannot read your in-memory data even with hypervisor access. Use cases:

• Highly regulated workloads (PCI cardholder data, healthcare, financial)
• Multi-tenant trust scenarios — multiple customers’ data on one VM with cryptographic isolation
• Insider-threat reduction at the cloud provider level

Performance overhead: ~5-10%. Worth it where data sensitivity warrants.

Confidential GKE Nodes

Same hardware-level encryption applied to GKE node memory. Combined with Workload Identity, gives strong cryptographic isolation for sensitive workloads.

External Key Manager (EKM)

For workloads where keys must remain outside Google’s infrastructure:

• Keys stored in your own HSM (or third-party KMS)
• GCP services request decryption from your KMS via Cloud KMS EKM connector
• You control key rotation, revocation, and audit independently
• Operational burden: your KMS becomes a critical dependency

Used in regulated industries that require keys-out-of-cloud-provider.

Assured Workloads

Pre-configured GCP environments meeting specific compliance regimes:

• FedRAMP Moderate / High
• IL2, IL4, IL5 (US DoD)
• HIPAA
• EU sovereignty controls

Provides environment with: data residency enforcement, employee location restrictions, encryption requirements, restricted services. Useful when regulated workloads need to demonstrate controls without re-implementing.

Organization Policy Service

Sets guardrails at organization or folder level — even owners can’t violate them at child scope:

• Restrict allowed regions — no resources outside India for data residency
• Disable service account key creation — force keyless
• Require OS Login for SSH (centralized identity, no metadata SSH keys)
• Disable default networks on new projects
• Restrict allowed external IPs on Compute Engine
• Require shielded VMs
• Disable allUsers / allAuthenticatedUsers in IAM

Set these at Organization level early. Retrofitting is much harder.

Networking advanced — Cloud Interconnect & Private Service Connect

• Dedicated Interconnect — physical fiber from your data centre to Google’s network. 10/100 Gbps. For high-bandwidth hybrid
• Partner Interconnect — through a partner; lower commitment
• Cloud VPN — IPsec; cheap; lower bandwidth
• Private Service Connect (PSC) — consume Google services or third-party services via private IPs in your VPC. Replaces some Service Endpoint use cases; finer control

India-specific considerations

• Mumbai (asia-south1) and Delhi (asia-south2) regions for data residency
• RBI cyber security framework + outsourcing requirements apply for banks
• DPDP — data residency increasingly relevant; Assured Workloads with India-only employee access
• NCIIPC implications for critical infrastructure on GCP

The maturity ladder

1. Beginner: projects organized by environment; default IAM; default networking
2. Intermediate: folder structure; Org Policies set; service accounts per-workload; Cloud Audit Logs to BigQuery
3. Advanced: VPC-SC perimeters; Workload Identity Federation everywhere; Security Command Center Premium; CMEK for sensitive data
4. Expert: Confidential Computing where warranted; EKM for highest sensitivity; Assured Workloads for regulated; BeyondCorp for internal apps

Closing the GCP track

This completes the GCP coverage. The cloud security track now spans AWS (Cloud Security M1-M7 in original tracks), Azure (M1-M3 here), and GCP (M1-M2 here) — a foundational base for cloud security work in any major provider.