VPC Service Controls, Org Policies and IAM on GCP: A Practical Security Guide

Quick Answer: GCP production security needs three layers working together. IAM decides who can do what, org policies decide what is allowed to exist, and VPC Service Controls decide where data can move. IAM alone cannot stop a compromised service-account key from copying a BigQuery table to an attacker’s bucket — VPC Service Controls is the layer that closes that hole, and it should be rolled out in dry-run mode before enforcement.

Why VPC Service Controls GCP Exists: The Gap IAM Leaves Open

Here is the scenario that justifies the entire feature. A service account in your project has roles/bigquery.dataViewer on a dataset holding customer PII. That is legitimate access. An attacker steals that service account’s JSON key — from a GitHub repo, a CI variable, a laptop backup. IAM evaluates two actions: read the dataset (allowed, the binding is real) and write to a bucket (allowed, if they have any storage role, or via a bucket in a project they control if egress is unchecked). Both actions are individually permitted. IAM has no opinion about the combination, and the data leaves.

This is the classic confused-deputy or data-exfiltration path, and it is not theoretical. VPC Service Controls (VPC-SC) draws a perimeter around a set of projects and restricts which Google APIs can move data across that boundary. It does not replace IAM — IAM still applies inside the perimeter — it adds a second gate that a stolen credential alone cannot pass from outside.

The Three Layers, and What Each One Actually Enforces

The ordering matters. IAM is your first and largest surface, org policies are cheap constraints you can apply broadly in days, and VPC-SC is a deliberate architectural change that needs design and testing. Most mature GCP estates apply all three, in that order.

IAM in Practice: Hierarchy, Least Privilege and Service Accounts

GCP IAM attaches at four levels — organization, folder, project, resource — and bindings cascade downward. The practical rules that hold up under audit: grant roles at the lowest node that works, prefer groups over individual users, and treat every service account as a machine identity with an owner and an expiry date. Basic roles (Owner, Editor, Viewer) should be effectively banned outside a handful of break-glass accounts; they grant far more than any workload needs.

# Least-privilege binding: workload SA gets data editor on ONE project only
gcloud projects add-iam-policy-binding my-ml-project 
  --member=serviceAccount:[email protected] 
  --role=roles/bigquery.dataEditor

The uncomfortable truth about IAM on large GCP estates: the failure mode is rarely a wrong binding, it is accumulation. Six teams add bindings over three years, nobody removes anything, and a contractor’s account still has dataViewer on the customer dataset. Quarterly binding reviews with a named owner per project are the only thing that reliably fixes this.

Org Policies: Constraining What Is Allowed to Exist

Org policies are the cheapest win in this guide. They are constraints applied at the organization, folder or project level, and they stop risky configurations before they are created. The ones worth applying first on any Indian enterprise GCP estate:

• iam.disableServiceAccountKeyCreation — forces workloads onto attached service accounts or Workload Identity Federation. This one constraint eliminates most key-leak incidents.
• iam.disableServiceAccountKeyUpload — blocks uploading externally generated keys.
• compute.vmExternalIpAccess — denies external IPs on VMs where they are not needed.
• iam.allowedPolicyMemberDomains — domain-restricted sharing, which stops data being shared with any arbitrary Gmail identity.
• storage.uniformBucketLevelAccess — removes per-object ACL ambiguity.

# org-policy.yaml — block service-account key creation at org level
name: organizations/987654321000/policies/iam.disableServiceAccountKeyCreation
spec:
  rules:
    - inheritFromParent: true
      values:
        allowedValues:
          - "true"

Every org policy supports a dry-run mode. Use it: set the constraint, run in dry-run, review the violation report for two weeks, then enforce. Enforcing disableServiceAccountKeyCreation without dry-run on an estate with legacy keys will break something that nobody documented.

VPC Service Controls: Building the Perimeter

A VPC-SC perimeter names a set of projects and a list of restricted services. Inside the perimeter, traffic between those projects works normally. Crossing the boundary — pulling data out to a project or account outside — is blocked unless an ingress or egress policy explicitly allows it. Restrict the services that actually hold data: BigQuery, Cloud Storage, Vertex AI, Pub/Sub, and Artifact Registry, at minimum.

Start in dry-run. The dry-run perimeter evaluates and logs violations without enforcing them, which is how you find the CI pipeline that will break before your users find it for you:

# Create the perimeter in DRY-RUN mode first — always
gcloud access-context-manager perimeters dry-run create 
  --title=ml-data-perimeter 
  --resources=projects/123456789012,projects/210987654321 
  --restricted-services=bigquery.googleapis.com,storage.googleapis.com,ml.googleapis.com 
  --policy=organizations/987654321000/policies/accessPolicy

Two operational details that bite teams. First, once a perimeter is enforced, you lose ordinary console and CLI access to those projects from outside — plan an access level (Context-Aware Access with a managed device, or Private Service Connect endpoints) before enforcement day, or your own admins get locked out of BigQuery. Second, perimeters can be bridged to connect two perimeters temporarily; useful for migration, dangerous if it becomes permanent.

And the limit worth stating plainly: VPC-SC does not protect against a compromised credential already inside the perimeter. If the stolen key belongs to a service account inside the protected projects, egress restrictions do not stop it. That is why the org policy on key creation and short audit cycles are part of the same programme, not separate initiatives.

A War Story: The Key That Left With the Data

An ML services company in Bangalore ran customer churn models on BigQuery for a retail client. A contractor built a training pipeline, and — because the CI system needed broad access and nobody had set up Workload Identity Federation — his script authenticated with a service-account JSON key committed to a private GitHub repo. The service account had dataViewer on the churn dataset and storage.admin in the same project. The key sat there for fourteen months.

The dataset was not enormous — roughly 40 GB of customer records with names, phone numbers and purchase history — but it was clearly client PII. When the repo was finally spotted during a routine GitHub org scan, the perimeter work that had been discussed for a year was still sitting in a design document. The remediation cost far exceeded the prevention: keys disabled and rotated, BigQuery audit logs pulled back across the full window to establish scope, a client notification under India’s DPDP obligations negotiated over three weeks, and two engineers pulled off feature work for a month.

The fixes that stuck afterwards: iam.disableServiceAccountKeyCreation enforced org-wide, Workload Identity Federation for the CI system, a VPC-SC perimeter in dry-run for six weeks before enforcement, and Security Command Center findings wired into their alerting. The org policy alone, applied a year earlier, would have made the incident impossible in that form.

The Rollout Order That Actually Works

1. IAM cleanup — remove basic roles from humans and machines, convert to predefined or custom roles, group bindings by team with an owner.
2. Org policies in dry-run — key creation, external IP, domain-restricted sharing. Review violations for two weeks.
3. Org policies enforced — with a documented break-glass exception path.
4. VPC-SC perimeter in dry-run — restricted services chosen, violations triaged, access path for admins designed.
5. Perimeter enforced — with Private Service Connect for admin access and an alert on any perimeter change.

Teams that start at step 4 usually roll back within a week. Teams that do steps 1–3 first find that the perimeter is the least eventful part.

Is This Where the Salary Is Going?

GCP security engineering is one of the better-paid cloud specialisms in India right now — mid-level cloud security roles typically run ₹18–35 LPA, with regulated industries (banking, fintech, healthcare) paying the top of that range precisely because work like this is mandatory for them. The AWS cloud security salary data tracks the AWS-side equivalent; the GCP premium is similar in shape. If you are comparing platform fundamentals before specialising, the Google Cloud engineer salary guide shows the general track. Networking intuition transfers from AWS too — the AWS VPC explainer covers the mental model that perimeters extend.

Training Resources

Build this properly with SkilBrill Google Cloud Security Training — IAM hierarchy, org policies and VPC Service Controls covered as a single programme with hands-on perimeter labs, not as isolated topics.

FAQ

What are VPC Service Controls in GCP?

A perimeter-based guardrail that restricts which Google services can move data in and out of a set of projects. IAM still applies inside the perimeter; VPC-SC adds a boundary that blocks cross-boundary data movement even when a credential is valid.

How are org policies different from IAM on GCP?

IAM grants or denies actions for principals. Org policies constrain how resources can be configured, regardless of who is asking — for example, blocking service-account key creation entirely. They operate on the resource hierarchy, not on identities.

Do VPC Service Controls replace IAM?

No. They are complementary. IAM controls who can act; VPC-SC controls where data can move. A perimeter without least-privilege IAM still leaves insider and compromised-credential risk entirely open.

Can VPC Service Controls stop a compromised service-account key?

Only partially. If the key belongs to a principal outside the perimeter, egress is blocked. If the compromised identity is already inside the perimeter, VPC-SC does not help — that is what key-creation org policies, Workload Identity Federation and audit alerting are for.

How do I test VPC Service Controls without breaking production?

Build every perimeter in dry-run mode first. Dry-run logs violations without enforcing them, giving you two to four weeks to fix CI pipelines, cross-project analytics jobs and admin access before anything is blocked.

Written by SkilBrill Training Institute

October 15, 2026 · 9 min read