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.
APIs and service perimeters
The following APIs can be added to the list of services that you want to protect with a service perimeter:
|APIs and service addresses|
|Cloud Bigtable API||bigtable.googleapis.com|
|Cloud Dataflow API||dataflow.googleapis.com|
|Cloud Dataproc API||dataproc.googleapis.com|
|Cloud Key Management Service API||cloudkms.googleapis.com|
|Cloud Pub/Sub API||pubsub.googleapis.com|
|Cloud Spanner API||spanner.googleapis.com|
|Cloud Storage API||storage.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|
|Stackdriver Logging API||logging.googleapis.com|
VPC Service Controls supports the following products.
For more information, read about supported and unsupported services.
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 Platform (GCP) 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.
- App Engine (both standard environment and flexible environment) is not supported. To allow App Engine apps created in projects outside the perimeter to read and write data to resources protected by a service perimeter, create an access level that includes the project's App Engine service account.
The BigQuery Data Transfer Service is not supported.
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.
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. To allow Cloud Build instances outside the perimeter to read and write data to resources protected by a service perimeter, create an access level that includes the project's Cloud Build service account.
Cloud Spanner cannot be used with Cloud Dataflow when the Cloud Dataflow project is protected by a service perimeter.
- Custom BIND and the
restricted.googleapis.comVIP cannot be used for Cloud Dataflow because DNS resolution of Cloud Dataflow can't be customized.
- The Cloud Datastore page in the GCP Console is not accessible if the Cloud Datastore instance is protected by a service perimeter.
To protect a Cloud 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 Dataproc Component Gateway does not support VPC Service Controls.
- The Cloud Firestore page in the GCP Console is not accessible if the Cloud Firestore instance is protected by a service perimeter.
Cloud Functions is not supported. To allow functions defined in projects outside the perimeter to read and write data to resources protected by a service perimeter, create an access level that includes the project's Cloud Functions service account.
Functions cannot be created for a project in a perimeter that protects the Cloud Storage service.
- VPC Service Controls policy only applies to new Cloud Pub/Sub push subscriptions. VPC Service Controls will not block push subscriptions that were created prior to a service perimeter.
- Cloud Shell is not supported. It is treated as outside of service perimeters and denied access to data protected by VPC Service Controls.
For projects in a service perimeter, the Cloud Storage page in the GCP 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.
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 Platform Console
Because the GCP Console is only accessible over the internet, it is treated as outside of service perimeters. When you apply a service perimeter, the GCP 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 GCP Console.
To allow access from the GCP 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 GCP 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 GCP 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 GCP Console.
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:
- While Monitoring can sometimes be used with projects protected by a service perimeter, Monitoring is not officially supported by VPC Service Controls.