This page contains a table of products and services that are supported by VPC Service Controls, as well as a list of known limitations with certain services and interfaces.
VPC Service Controls supports the following products:
For more information, read about supported and unsupported services.
APIs and service perimeters
Not all products that are supported by VPC Service Controls have a service that can be protected by a service perimeter. Only the following APIs can be protected with a perimeter:
|APIs and service addresses|
|Access Approval API||accessapproval.googleapis.com|
|AI Platform Training and Prediction API||ml.googleapis.com|
|Artifact Registry API||artifactregistry.googleapis.com|
|Cloud Bigtable API||bigtable.googleapis.com|
|Cloud Asset Inventory API||cloudasset.googleapis.com|
|Data Catalog API||datacatalog.googleapis.com|
|Cloud Data Fusion API||datafusion.googleapis.com|
|Cloud Data Loss Prevention API||dlp.googleapis.com|
|Cloud Functions API||cloudfunctions.googleapis.com|
|Cloud Key Management Service API||cloudkms.googleapis.com|
|Secret Manager API||secretmanager.googleapis.com|
|Cloud Natural Language API||language.googleapis.com|
|Managed Service for Microsoft Active Directory API||managedidentities.googleapis.com|
|Cloud Service Mesh Certificate Authority API||meshca.googleapis.com|
|Cloud Spanner API||spanner.googleapis.com|
|Cloud Storage API||storage.googleapis.com|
|Storage Transfer Service API||storagetransfer.googleapis.com|
|Cloud SQL API||sqladmin.googleapis.com|
|Cloud Vision API||vision.googleapis.com|
|Container Analysis API||containeranalysis.googleapis.com|
|Container Registry API||containerregistry.googleapis.com|
|Google Kubernetes Engine API||container.googleapis.com|
|GKE Connect API||gkeconnect.googleapis.com|
|GKE Hub API||gkehub.googleapis.com|
|Resource Manager API||cloudresourcemanager.googleapis.com|
|Cloud Logging API||logging.googleapis.com|
|Memorystore for Redis API||redis.googleapis.com|
|Cloud Monitoring API||monitoring.googleapis.com|
|Cloud Profiler API||profiler.googleapis.com|
|Cloud Translation API||translate.googleapis.com|
|Cloud Trace API||cloudtrace.googleapis.com|
|Cloud TPU API||tpu.googleapis.com|
|Video Intelligence API||videointelligence.googleapis.com|
|Cloud Healthcare API||healthcare.googleapis.com|
Restricted VIP supported services
The restricted virtual IP (VIP) provides a way for VMs that are inside a service perimeter to make calls to Google Cloud services without exposing the requests to the internet. For a complete list of the services available on the restricted VIP, see Services supported by the restricted VIP.
Attempting to restrict an unsupported service using the
gcloud command-line tool or
the Access Context Manager API will result in an error.
Cross-project access to data of supported services will be blocked by VPC Service Controls. Additionally, the restricted VIP can be used to block the ability of workloads to call unsupported services.
This section describes known limitations with certain Google Cloud services, products, and interfaces that can be encountered when using VPC Service Controls.
For more information on resolving issues with VPC Service Controls, refer to the Troubleshooting page.
AI Platform Training
To fully protect your AI Platform Training training jobs, add all of the following APIs to the service perimeter:
- AI Platform Training and Prediction API (
- Pub/Sub API (
- Cloud Storage API (
- Google Kubernetes Engine API (
- Container Registry API (
- Cloud Logging API (
Read more about setting up VPC Service Controls for AI Platform Training.
- AI Platform Training and Prediction API (
Training with TPUs is not supported when you use AI Platform Training inside a service perimeter.
When you protect the AI Platform Training and Prediction API by using a service perimeter, you only protect AI Platform Training, not AI Platform Prediction. However, some AI Platform Prediction functionality is disabled.
AI Platform Notebooks
To use AI Platform Notebooks within a VPC Service Controls service perimeter, you must add or configure several DNS entries to point the following domains to the restricted VIP:
App Engine (both standard environment and flexible environment) is not supported by VPC Service Controls. Do not include App Engine projects in service perimeters.
However, it is possible to allow App Engine apps created in projects outside service perimeters to read and write data to protected services inside perimeters. To allow your app to access the data of protected services, create an access level that includes the project's App Engine service account. This does not enable App Engine to be used inside service perimeters.
Because it is not using the
googleapis.com domain, Artifact Registry
must be configured via Private DNS or BIND to map to the restricted VIP
separately from other APIs. For more information, see
Securing repositories in a service perimeter.
VPC Service Controls does not support copying BigQuery resources protected by a service perimeter to another organization. Access levels do not enable you to copy across organizations.
To copy protected BigQuery resources to another organization, download the dataset (for example, as a CSV file), and then upload that file to the other organization.
The BigQuery Data Transfer Service is supported only for the following services:
- Campaign Manager
- Google Ad Manager
- Google Ads
- Google Cloud Storage
- Google Merchant Center
- Google Play
The BigQuery Classic Web UI is not supported. A BigQuery instance protected by a service perimeter cannot be accessed with the BigQuery Classic Web UI.
The third-party ODBC driver for BigQuery cannot currently be used with the restricted VIP.
BigQuery audit log records do not always include all resources that were used when a request is made, due to the service internally processing access to multiple resources.
When using a service account to access a BigQuery instance protected by a service perimeter, the BigQuery job must be run within a project inside the perimeter. By default, the BigQuery client libraries will run jobs within the service account or user's project, causing the query to be rejected by VPC Service Controls.
The Java and Python client libraries for all supported services are fully supported for access using the restricted VIP. Support for others language is at Alpha stage and should be used for testing purposes only.
Clients must use client libraries that have been updated as of November 1, 2018 or later.
Service account keys or OAuth2 client metadata used by clients must be updated as of November 1, 2018 or later. Older clients using the token endpoint must change to the endpoint specified in newer key material/client metadata.
- To allow Cloud Billing export to a Cloud Storage bucket or BigQuery instance in a project protected by a service perimeter, the user that is configuring the export should be added temporarily to an access level for the perimeter.
Cloud Build is not supported by VPC Service Controls. Do not use Cloud Build inside service perimeters.
However, it is possible to allow Cloud Build in projects outside service perimeters to read and write data to protected services inside perimeters. To allow Cloud Build to access the data of protected services, create an access level that includes the project's Cloud Build service account. This does not enable Cloud Build to be used inside service perimeters.
Cloud Composer is not supported by VPC Service Controls. Do not use Cloud Composer inside service perimeters.
To allow Cloud Composer to access resources inside a service perimeter, enable Cloud Composer in a project outside any service perimeter. Then, create and apply an access level to the perimeter that allows requests from the service account for your Cloud Composer environment.
Cloud Data Fusion
Establish the VPC Service Controls security perimeter before creating your Cloud Data Fusion private instance. Perimeter protection for instances created prior to setting up VPC Service Controls is not supported.
Currently, the Cloud Data Fusion data plane UI does not support specifying access levels using identity based access.
For more information, see Using VPC Service Controls with Cloud Data Fusion.
- Custom BIND is not supported when using Dataflow. To customize DNS resolution when using Dataflow with VPC Service Controls, use Cloud DNS private zones instead of using custom BIND servers. To use your own on-premises DNS resolution, consider using a Google Cloud DNS forwarding method.
Not all storage service connectors have been verified to work when used with Dataflow inside a service perimeter. For a list of verified connectors, see the Dataflow details.
- To protect a Dataproc cluster with a service perimeter, you must follow the instructions for setting up private connectivity to allow the cluster to function inside the perimeter.
Cloud Functions uses Cloud Build to build your source code into a runnable container. In order to use Cloud Functions inside a service perimeter, you must configure an access level for the Cloud Build Service Account in your service perimeter.
To allow your functions to use external dependencies such as npm packages, Cloud Build has unlimited internet access. This internet access could be used to exfiltrate data that is available at build time, such as your uploaded source code. If you want to mitigate this exfiltration vector, we recommend that you only allow trusted developers to deploy functions. Do not grant Cloud Functions Owner, Editor, or Developer IAM roles to untrusted developers.
For Firebase Realtime Database triggers and Firebase Crashlytics triggers, a user could deploy a function that could be triggered by changes to a Firebase Realtime Database or Firebase Crashlytics in a different project outside the service perimeter of the project in which the function is deployed. If you want to mitigate the exfiltration vector for these two triggers, we recommend that you only allow trusted developers to deploy functions. Do not grant Cloud Functions Owner, Editor, or Developer IAM roles to untrusted developers.
- In projects protected by a service perimeter, new push subscriptions cannot be created.
- Pub/Sub push subscriptions created prior to the service perimeter will not be blocked.
- Cloud Shell is not supported. It is treated as outside of service perimeters and denied access to data protected by VPC Service Controls.
When using the Requester Pays feature with a storage bucket inside a service perimeter that protects the Cloud Storage service, you cannot identify a project to pay that is outside the perimeter. The target project must be in the same perimeter as the storage bucket or in a perimeter bridge with the bucket's project.
For more information about Requester Pays, see the Requester Pays use and access requirements.
For projects in a service perimeter, the Cloud Storage page in the Cloud Console is not accessible if the Cloud Storage API is protected by that perimeter. If you want to grant access to the page, you must create an access level that includes either the user accounts or a public IP range that you want to allow to access the Cloud Storage API.
In audit log records, the
resourceNamefield does not identify the project that owns a bucket. The project must be discovered separately.
In audit log records, the value for
methodNameis not always correct. We recommend that you do not filter Cloud Storage audit log records by
In certain cases, Cloud Storage legacy bucket logs can be written to destinations outside of a service perimeter even when access is denied.
When you attempt to use
gsutilfor the first time in a new project, you may be prompted to enable the
storage-api.googleapis.comservice. While you cannot directly protect
storage-api.googleapis.com, when you protect the Cloud Storage API using a service perimeter,
gsutiloperations are also protected.
Currently, you cannot protect the Compute Engine API using a service perimeter.
To enable creating a Compute Engine image from a Cloud Storage in a project protected by a service perimeter, the user that is creating the image should be added temporarily to an access level for the perimeter.
Using Kubernetes with Compute Engine inside a service perimeter is not supported by VPC Service Controls.
Because it is not using the
googleapis.comdomain, Container Registry must be configured via Private DNS or BIND to map to the restricted VIP separately from other APIs. For more information, see Securing Container Registry in a service perimeter.
In addition to the containers inside a perimeter that are available to Container Registry, the following read-only Google-managed repositories are available to all projects regardless of service perimeters:
In all cases, the regional versions of these repositories are also available.
Google Cloud Console
Because the Cloud Console is only accessible over the internet, it is treated as outside of service perimeters. When you apply a service perimeter, the Cloud Console interface for the services that you protected may become partially or fully inaccessible. For example, if you protected Logging with the perimeter, you will not be able to access the Logging interface in the Cloud Console.
To allow access from the Cloud Console to resources protected by a perimeter, you need to create an access level for a public IP range that includes the machines of users who want to use the Cloud Console with protected APIs. For example, you could add the public IP range of the NAT gateway of your private network to an access level, and then assign that access level to the service perimeter.
If you want to limit Cloud Console access to the perimeter to only a specific set of users, you can also add those users to an access level. In that case, only the specified users would be able to access the Cloud Console.
- The only Resource Manager API methods that are protected are
Aggregated export sinks (folder or organization sinks where
true) can access data from projects inside a service perimeter. We recommend that Cloud IAM is used to manage Logging permissions at the folder and organization level.
Because VPC Service Controls does not currently support folder and organization resources, log exports of folder-level and organization-level logs (including aggregate logs) do not support service perimeters. We recommend that Cloud IAM is used to restrict exports to the service accounts required to interact with the perimeter-protected services.
To set up an organization or folder log export to a resource protected by a service perimeter, you must add the service account for that log sink to an access level and then assign it to the destination service perimeter. This is not necessary for project-level log exports.
For more information, refer to the following pages:
Memorystore for Redis
Service perimeters protect only the Memorystore for Redis API. Perimeters do not protect normal data access on Memorystore for Redis instances within the same network.
If the Cloud Storage API is also protected, then Memorystore for Redis import and export operations can only read and write to a Cloud Storage bucket within the same service perimeter as the Memorystore for Redis instance.
Notification channels, alerting policies, and custom metrics can be used together to exfiltrate data/metadata. As of today, a user of Monitoring can set up a notification channel that points to an entity outside of the organization e.g. "firstname.lastname@example.org". The user then sets up custom metrics and corresponding alert policies that utilize the notification channel. As a result, by manipulating the custom metrics, the user can trigger alerts and send alert firing notifications, exfiltrating sensitive data to email@example.com, outside of the VPC Service Controls perimeter.
While Monitoring in Google Cloud Console supports VPC Service Controls, VPC Service Controls for the classic Cloud Monitoring console are not fully supported.
Any Compute Engine or AWS VMs with the Monitoring Agent installed must be inside the VPC Service Controls perimeter or agent metric writes will fail.
When querying metrics for a workspace only the VPC Service Controls perimeter of the workspace's host project is considered, not the perimeters of the individual monitored projects in the workspace.
A project can only be added as a monitored project to an existing workspace if that project is in the same VPC Service Controls perimeter as the workspace's host project.
To access Monitoring in the Cloud Console for a host project that is protected by a service perimeter, use access levels.
Cloud Asset API
- When calling Cloud Asset API at the Folder or Organization level, data from projects inside a service perimeter that belongs to the folder or organization can still be accessed. We recommend that Cloud IAM is used to manage Cloud Asset Inventory permissions at the folder and organization level.
Service perimeters protect only the Cloud SQL Admin API. They do not protect IP-based data access to Cloud SQL instances. You need to use an organization policy constraint to restrict public IP access on Cloud SQL instances.
Cloud SQL imports and exports can only perform reads and writes from a Cloud Storage bucket within the same service perimeter as the Cloud SQL replica instance. In the external server migration flow, you need to add the Cloud Storage bucket to the same service perimeter. When creating a key flow for CMEK, you need to create the key in the same service perimeter as the resources that use it. Note: When restoring an instance from a backup, the target instance need to reside in the same service perimeter as the backup.
Storage Transfer Service
- Transfer service for on-premises data doesn't offer an API, and therefore does not support API-related features in VPC Service Controls.
- When you call the Service Control API from a VPC network in a service perimeter with Service Control restricted, you can't use the Service Control report method to report billing and analytics metrics.