IAM + VPC Service Controls: A Fast GCP Defense-in-Depth Security Pattern

Overview

Google Cloud security should never depend on a single control.

Identity and Access Management determines who can access a resource and what that identity is allowed to do. VPC Service Controls adds another layer by considering the security perimeter and context from which protected Google Cloud services are accessed.

Together, they create a powerful defense-in-depth model:

IAM controls identity and permissions. VPC Service Controls limits where protected data can move and the contexts from which it can be accessed.

This combination can reduce the impact of:

Stolen user credentials
Leaked service-account credentials
Excessive IAM permissions
Accidentally public resources
Compromised workloads
Malicious insiders
Unauthorized cross-project data transfers
Data exfiltration from managed Google Cloud services

The underlying security principle can be understood in two minutes. A production implementation, however, requires careful planning, testing, logging, and application-dependency analysis.

The Two Main Security Boundaries

A practical Google Cloud security design can begin with two complementary boundaries:

The project and IAM boundary
The VPC Service Controls perimeter

The project boundary helps organize resources, permissions, billing, APIs, and lifecycle management. VPC Service Controls adds an independent data-security perimeter around supported Google-managed services.

Neither boundary is sufficient by itself.

Boundary One: Projects and IAM

Projects are one of the most important administrative boundaries in Google Cloud.

A project contains or owns resources such as:

Compute Engine instances
Cloud Storage buckets
BigQuery datasets
Pub/Sub topics
Secret Manager secrets
Service accounts
VPC networks
Cloud KMS resources
Vertex AI resources

A project also serves as an important boundary for:

IAM policies
Billing attribution
API enablement
Quotas
Logging
Monitoring
Resource lifecycle
Security administration

Separating applications, environments, and security domains into different projects can reduce the impact of a compromised identity or misconfiguration.

For example:

Organization
├── Production folder
│   ├── Payments project
│   ├── Customer-data project
│   └── Analytics project
│
├── Nonproduction folder
│   ├── Development project
│   └── Testing project
│
└── Shared-services folder
    ├── Networking project
    ├── Security project
    └── Logging project

If production and development resources are placed in the same project, an overly broad project-level role could expose both environments. Separating them into different projects allows organizations to create clearer administrative and security boundaries.

However, a project is not an absolute isolation boundary. IAM roles can be inherited from folders and the organization, and identities can be granted access across projects. Project separation works only when it is supported by properly designed IAM policies.

What IAM Does

Google Cloud IAM determines:

Which principal is requesting access
Which role has been granted to that principal
Which permissions are contained in that role
Which resource the policy applies to
Whether any IAM conditions apply
Whether an organization or IAM deny policy blocks the request

A principal can be:

A human user
A Google group
A service account
A workforce identity
A workload identity
An external federated identity

A simplified IAM decision looks like this:

Principal
   +
Assigned role
   +
Resource policy
   +
Policy conditions
   =
Allow or deny

For example, a service account might be granted permission to read objects from a particular Cloud Storage bucket.

IAM answers:

Is this identity authorized to perform this operation on this resource?

IAM does not, by itself, always answer:

Is this request coming from an approved network or device?

It also does not always prevent an authorized identity from copying protected data to an unauthorized resource.

That is where VPC Service Controls becomes valuable.

A Fast IAM Security Baseline

A strong IAM baseline should include the following controls.

Use Groups for Human Access

Assign IAM roles to groups rather than directly to individual users.

For example:

[email protected]
[email protected]
[email protected]
[email protected]

When employees change roles or leave the organization, their group membership can be updated centrally.

Groups can be managed through Google Workspace or Cloud Identity. Enterprises using an external identity provider can federate their workforce identities into Google Cloud.

Enforce Single Sign-On and MFA

Human administrators should authenticate through the organization’s identity provider using single sign-on and strong multifactor authentication.

This provides:

Centralized authentication
Consistent account-lifecycle management
Corporate MFA enforcement
Conditional-access controls
Centralized login monitoring
Faster revocation of access

Apply Least Privilege

Avoid granting broad roles such as:

Owner
Editor
Organization Administrator
Project IAM Administrator

Use predefined or custom roles that contain only the required permissions.

For example, a user who needs to view logs should not automatically receive permission to modify virtual machines.

Avoid Long-Lived Service-Account Keys

Service-account keys are high-risk credentials because they can be copied, leaked, or committed to a source-code repository.

Whenever possible, use:

Attached service accounts for Google Cloud workloads
Service-account impersonation
Workload Identity Federation
Workforce Identity Federation
Short-lived credentials
Managed workload identities

If service-account keys cannot be eliminated, tightly control their creation, rotate them, monitor their use, and scan repositories for accidental exposure.

See: GCP Service Accounts Best Practices

Separate Environments and Applications

Use different projects for:

Production and nonproduction
Sensitive and nonsensitive data
Independent applications
Regulated workloads
Shared infrastructure
Security and logging

Project separation reduces the number of resources affected by a single project-level IAM error.

Why IAM Alone Is Not Enough

Imagine that a service account legitimately has permission to read sensitive objects from a Cloud Storage bucket.

Now assume that its credential is accidentally committed to a public GitHub repository.

An attacker obtains the credential and sends a valid request to the Cloud Storage API.

From an IAM perspective:

The credential is valid.
The service account exists.
The service account has permission.
The requested operation is allowed.

IAM might therefore authorize the request.

Even though the person using the credential is an attacker, IAM sees a valid identity with valid permissions.

VPC Service Controls can provide an additional decision point. If the request originates outside the trusted perimeter and does not satisfy an approved ingress rule or access level, it can be denied—even when IAM would otherwise permit it.

What Are VPC Service Controls?

VPC Service Controls allows organizations to create security perimeters around resources and data in supported Google-managed services.

Common examples include:

Cloud Storage
BigQuery
Pub/Sub
Secret Manager
Cloud KMS
Artifact Registry
Vertex AI
Other supported Google Cloud APIs

The exact list of supported services changes over time and should always be checked against the current VPC Service Controls supported-products documentation.

A service perimeter can restrict:

Requests from the public internet
Requests from unauthorized VPC networks
Requests from unauthorized projects
Access between separate service perimeters
Data movement to resources outside the perimeter
Access based on identity, IP address, device, or request origin

Google recommends using VPC Service Controls with IAM as independent, complementary layers. Google Cloud’s VPC Service Controls overview

Why Is “VPC” in the Name?

The name can be misleading.

VPC Service Controls is not a conventional network firewall, and a VPC network is not required for every possible use case.

It does not inspect arbitrary TCP or UDP traffic between systems. It primarily controls API-based access to supported Google-managed services.

For example, a Cloud Storage request is generally sent to a Google API endpoint. The request is authenticated and authorized through IAM rather than being treated like a connection to a server inside the customer’s subnet.

VPC Service Controls adds perimeter-based policy checks to these Google-managed API requests.

It can use VPC network origin as part of the trust decision, but the control operates at the Google service and API layer—not as a traditional VPC firewall rule.

How IAM and VPC Service Controls Work Together

IAM and VPC Service Controls perform separate evaluations.

A request generally needs to satisfy both:

IAM authorization
        +
VPC Service Controls perimeter policy
        =
Access allowed

Consider the following situations:

IAM decision	Perimeter decision	Result
Allow	Allow	Request succeeds
Allow	Deny	Request fails
Deny	Allow	Request fails
Deny	Deny	Request fails

VPC Service Controls does not grant permissions. It can only add restrictions to requests that IAM might otherwise permit.

This is the essence of defense in depth.

Example: Compromised Service-Account Credential

Consider a sensitive Cloud Storage bucket protected by IAM and a service perimeter.

The authorized application runs inside an approved Google Cloud environment.

Normal Request

Authorized workload
        |
        | Valid service-account identity
        | Approved VPC or perimeter context
        v
IAM check: Allow
Perimeter check: Allow
        |
        v
Cloud Storage access succeeds

Request Using Stolen Credentials

Attacker outside the trusted environment
        |
        | Stolen service-account credential
        | Unapproved network or request context
        v
IAM check: Allow
Perimeter check: Deny
        |
        v
Cloud Storage access fails

The credential still needs to be revoked and the incident investigated, but the perimeter can reduce the immediate risk of unauthorized data access or exfiltration.

What Is a Service Perimeter?

A service perimeter defines a security boundary around selected Google Cloud resources and supported services.

A perimeter configuration typically identifies:

Projects or VPC networks included in the perimeter
Google Cloud services restricted by the perimeter
Access levels for approved external requests
Ingress rules for traffic entering the perimeter
Egress rules for traffic leaving the perimeter
Exceptions required by applications or administrators

Resources within the same perimeter can generally communicate with one another through protected services, subject to IAM and other applicable controls.

Requests that cross the perimeter are denied unless they are explicitly allowed.

Protecting Data Rather Than Simply Protecting Networks

The primary purpose of VPC Service Controls is to reduce data-exfiltration risk.

For example, assume:

Project A contains a sensitive Cloud Storage bucket.
Project B contains an unauthorized bucket.
The service account in Project A has excessive permissions.

Without an appropriate perimeter, a compromised workload might attempt to copy data from the protected bucket to the unauthorized bucket.

A VPC Service Controls perimeter can block that cross-boundary transfer unless an egress rule explicitly permits it.

This is different from a traditional firewall. The control follows supported Google service operations and resource boundaries rather than simply inspecting source and destination IP addresses.

Access Context Manager

Access Context Manager works with VPC Service Controls to define context-aware access requirements.

An access level can evaluate attributes such as:

Source IP address
User or service-account identity
Device status
Operating system
Geographic origin
VPC network origin
Google Cloud project origin

For example, an organization might define an access level that requires:

Corporate identity
AND
Managed device
AND
Approved operating system
AND
Corporate public IP range

The access level can then be referenced by a service perimeter or ingress rule.

This allows an organization to make decisions based on more than identity alone.

Allowing On-Premises Users to Access Protected Resources

Organizations frequently want on-premises users or workloads to access protected Cloud Storage, BigQuery, or other Google APIs.

A typical architecture includes:

An on-premises network
Cloud VPN or Cloud Interconnect
A Google Cloud landing-zone VPC
Private Google Access for on-premises hosts
DNS configuration for Google API endpoints
A VPC Service Controls perimeter
IAM permissions for the requesting identities

The landing-zone VPC or relevant VPC resource must be included in the perimeter design.

The connection path might look like this:

On-premises workload
        |
        | VPN or Cloud Interconnect
        v
Authorized Google Cloud VPC
        |
        | Private Google Access
        v
Protected Google API
        |
        | IAM and perimeter checks
        v
Cloud Storage, BigQuery or another supported service

A VPN tunnel by itself does not grant access. It provides network connectivity.

The user or workload must still:

Authenticate successfully
Have the required IAM permissions
Use an authorized path
Satisfy the service perimeter
Satisfy any applicable ingress rule or access level

Private Google Access

Private Google Access allows workloads with private IP addresses to reach Google APIs and services without requiring an external IP address on each VM.

For VMs inside Google Cloud, Private Google Access is enabled on the subnet.

This is useful for workloads such as:

Private Compute Engine instances
Private GKE nodes
Internal data-processing systems
Applications that should not have public IP addresses

Private Google Access provides the connectivity path. VPC Service Controls supplies the service-perimeter restrictions. IAM supplies identity-based authorization.

These controls solve different parts of the problem.

`private.googleapis.com` Versus `restricted.googleapis.com`

Google provides different virtual IP options for private API connectivity.

`private.googleapis.com`

This endpoint provides private connectivity to a broad range of Google APIs and services.

`restricted.googleapis.com`

This endpoint provides access to APIs and services supported by VPC Service Controls through a restricted virtual IP address.

The restricted endpoint can reduce the risk that workloads use the private API path to reach Google services that are not protected by the perimeter.

For highly controlled environments, DNS and routing are commonly configured so requests to supported Google APIs resolve to:

restricted.googleapis.com

The correct choice depends on which services the workloads need and whether those services are available through the restricted endpoint.

A Practical Four-Minute Extension

The basic two-layer model is:

IAM
+
VPC Service Controls

A stronger version adds private API connectivity:

IAM
+
VPC Service Controls
+
Private Google Access
+
restricted.googleapis.com

In this model:

Workloads do not require public IP addresses.
Google API requests use a private network path.
Supported managed services are protected by a service perimeter.
IAM still determines which operations each identity can perform.
Ingress and egress rules control legitimate perimeter crossings.

This is a stronger pattern, but it requires DNS, routing, service compatibility, and dependency testing.

How to Configure VPC Service Controls

The following is a conceptual implementation sequence.

Step 1: Create or Select an Access Policy

VPC Service Controls configurations are normally managed through an Access Context Manager access policy.

An organization can use an organization-level access policy or appropriately scoped policies where supported.

Step 2: Create Access Levels

Define approved request contexts, such as:

Corporate public IP ranges
Managed corporate devices
Approved identities
Authorized VPC networks
Trusted on-premises networks

Do not rely on IP address alone when stronger contextual signals are available.

Step 3: Create a Service Perimeter

Create a regular service perimeter and select the projects, resources, or VPC network resources that require protection.

Choose the supported services to restrict, such as:

Cloud Storage
BigQuery
Pub/Sub
Secret Manager
Cloud KMS
Other application dependencies

Step 4: Define Ingress Rules

Ingress rules allow approved clients outside the perimeter to access protected resources inside it.

An ingress rule can specify:

Source identity
Source project
Source VPC network
Access level
Target project or resource
Permitted service
Permitted API operations

Rules should be narrow and explicit.

Step 5: Define Egress Rules

Egress rules allow protected identities or resources inside the perimeter to access approved resources outside it.

For example, an analytics workload might need to write sanitized results to a project outside the sensitive-data perimeter.

The egress rule should allow only the required:

Identity
Destination
Service
Operation

Step 6: Configure Private Connectivity

For private workloads:

Remove unnecessary external IP addresses.
Enable Private Google Access on the relevant subnets.
Configure routes to the appropriate Google API virtual IP.
Configure private DNS for Google API domains.
Consider restricted.googleapis.com for VPC Service Controls-supported APIs.

Step 7: Start in Dry-Run Mode

VPC Service Controls can affect legitimate application and administrative workflows.

Use dry-run mode to observe which requests would be denied without actually blocking them.

Review:

Cloud Audit Logs
Application service-to-service calls
Data pipelines
Backup operations
CI/CD workflows
Managed-service agents
Administrator access
Cross-project dependencies
Third-party integrations

After the required ingress and egress rules have been validated, move the perimeter into enforcement mode.

What Cloud IAP Adds

Identity-Aware Proxy is another complementary security control, but it addresses a different problem.

Cloud IAP provides identity-aware access to applications and administrative interfaces.

For TCP forwarding, IAP can support SSH or RDP access to a private Compute Engine instance without assigning the VM a public IP address and without requiring a traditional user VPN.

A simplified flow is:

Administrator
        |
        | HTTPS connection to IAP
        | Identity and IAM verification
        v
Identity-Aware Proxy
        |
        | IAP TCP tunnel
        v
Private Compute Engine VM

IAP does not eliminate the need for:

IAM permissions
Firewall rules allowing IAP traffic
Operating-system authentication
OS Login or another account-management method
Logging and monitoring
Least-privilege administration

IAP protects access to applications and VM administrative interfaces. VPC Service Controls protects supported Google-managed service APIs and data movement. They solve different security problems.

What VPC Service Controls Does Not Do

VPC Service Controls is powerful, but it is not a complete security solution.

It does not replace:

IAM
VPC firewall rules
Hierarchical firewall policies
Cloud Armor
Encryption
Data Loss Prevention controls
Endpoint security
Secret management
Security Command Center
Application security
SIEM and incident response
Organization Policy constraints

It also does not act as a general-purpose internet firewall. A service perimeter does not automatically prevent a workload from communicating with arbitrary third-party internet services.

Additional network egress controls are still required.

Limitations and Design Considerations

Not Every Service Is Supported

VPC Service Controls supports many important Google Cloud services, but not every service or API operation is fully integrated.

Always review:

Whether the service is supported
Whether its integration is generally available or in preview
Whether it works with the restricted VIP
Whether known limitations apply
Whether all required API methods are protected

The current supported list can also be retrieved with:

gcloud access-context-manager supported-services list

Service Dependencies Can Be Complex

A service inside a perimeter might depend on:

Cloud Storage
Cloud Build
Artifact Registry
Logging
Monitoring
Secret Manager
Pub/Sub
A service agent in another project
An unsupported Google service
A third-party API

A perimeter can break these workflows if dependencies are not identified before enforcement.

Google Cloud Console Access Requires Planning

Administrators using the Google Cloud console might need access levels or ingress rules that permit their identities and network locations.

Without the appropriate rules, an administrator might be able to sign in to the console but be unable to view or manage protected resources.

Metadata Protection Is Not Comprehensive

The main purpose of VPC Service Controls is to control access to and movement of protected data.

It should not be treated as comprehensive protection for all resource metadata. IAM remains critical for controlling access to resource names, configuration data, and other metadata.

Perimeters Require Ongoing Maintenance

A perimeter is not a one-time configuration.

Ingress and egress requirements can change when:

New applications are deployed
Projects are moved
APIs are enabled
CI/CD systems change
Vendors are introduced
Data pipelines are modified
New managed services are adopted

Perimeter policies should be reviewed as part of normal architecture and change-management processes.

Recommended Defense-in-Depth Pattern

A mature Google Cloud security pattern can include:

Federated identities and MFA
             +
Group-based least-privilege IAM
             +
Separate projects and folders
             +
Organization Policy constraints
             +
VPC Service Controls
             +
Private Google Access
             +
restricted.googleapis.com
             +
Identity-Aware Proxy
             +
Centralized audit logging
             +
Security Command Center

Each control protects a different part of the architecture.

Control	Primary purpose
IAM	Determines who can perform which operation
Projects and folders	Organize resources and limit administrative scope
VPC Service Controls	Restricts access to and movement of protected service data
Access Context Manager	Evaluates identity, network, device, and request context
Private Google Access	Provides private access to Google APIs
Restricted VIP	Limits private API access to supported protected services
IAP	Provides identity-aware application, SSH, and RDP access
Organization Policy	Enforces organization-wide configuration guardrails
Audit Logs	Records administrative and data-access activity
Security Command Center	Identifies misconfigurations, threats, and vulnerabilities

A Two-Minute Security Checklist

At a minimum, ask these questions:

Are production resources separated into appropriately scoped projects?
Are IAM roles granted to groups rather than individual users?
Are broad Owner and Editor roles minimized?
Have long-lived service-account keys been eliminated where possible?
Are sensitive services protected by VPC Service Controls?
Are legitimate ingress and egress paths explicitly defined?
Are private workloads using Private Google Access?
Should Google API traffic use restricted.googleapis.com?
Is administrative access protected through IAP, VPN, or another controlled path?
Was the perimeter tested in dry-run mode before enforcement?
Are denied requests and perimeter violations monitored?
Has the application’s complete service-dependency map been documented?

If several answers are “no,” the environment likely has avoidable exposure.

Summary

IAM and VPC Service Controls are complementary—not competing—security mechanisms.

IAM determines:

Who is allowed to access the resource, and what can that identity do?

VPC Service Controls determines:

Is the request crossing an approved security perimeter, and is the movement of protected data permitted?

If a user or service-account credential is compromised, IAM alone might still authorize a request because the credential remains technically valid. VPC Service Controls can add another barrier by blocking requests from unauthorized contexts or preventing protected data from moving outside the perimeter.

The strongest pattern combines:

Federated identities
Group-based IAM
Least privilege
Project separation
Short-lived workload credentials
VPC Service Controls
Access Context Manager
Private Google Access
Restricted Google API endpoints
Identity-Aware Proxy
Centralized logging and monitoring

VPC Service Controls should not be viewed as a universal lock around every Google Cloud resource. It is a specialized control designed primarily to reduce data-exfiltration risk for supported Google-managed services.

When implemented carefully alongside IAM, it creates one of Google Cloud’s most valuable defense-in-depth security patterns.

Need an experienced AWS/GCP/Azure Professional to help out with your Public Cloud Strategy? Set up a time with Anuj Varma.