Controls to restrict access to individually approved APIs

Last reviewed 2024-02-06 UTC

Many organizations have a compliance requirement to restrict network access to an explicitly approved list of APIs, based on internal requirements or as part of adopting Assured Workloads. On-premises, this requirement is often addressed with proxy controls, but in your Google Virtual Private Cloud (VPC) you can address this requirement with the Restrict Resource Service Usage Organization Policy instead. This policy allows an administrator to define which Google Cloud resources can be created within their resource hierarchy, but to use this Organization Policy effectively, you must align various networking controls in your environment.

This document describes how to restrict access to individually approved Google APIs using the Organization Policy Service and other network controls, as well as the challenges with applying the on-premises proxy-based approach to Google Cloud services. This document is intended for network administrators or security teams who want to restrict which Google Cloud APIs can be reached from their VPC network endpoints.

Challenges with proxies for access control to Google APIs

In an on-premises network, your enterprise might have a compliance requirement to allow egress traffic only to approved services and domains. This requirement can be enforced by filtering egress traffic through a web proxy or secure access gateway. This proxy intercepts all outgoing traffic and allows egress only to explicitly approved APIs.

In some enterprises, you might similarly have a compliance requirement to restrict access from your VPC network to approved Google Cloud APIs. This compliance control is often seen in the following scenarios:

  • An enterprise is adopting Assured Workloads for sensitive workloads and compliance controls.
  • An enterprise has internal compliance requirements that network endpoints on Google Cloud are only allowed to access Google Cloud APIs approved through an internal process.
  • An enterprise wants to migrate infrastructure-as-a-service (IaaS) workloads to Google Cloud with minimal refactoring.
  • An enterprise has not yet developed controls for cloud and prefers to extend existing controls from the on-premises environment.

Although your enterprise might use a web proxy to control egress from its on-premises network to web services, we don't recommend this approach for controlling access from your VPC network to Google Cloud APIs. Using this proxy approach introduces scalability concerns, creates a single point of failure, and does not address data exfiltration risks using Google Cloud APIs.

We recommend using the Restrict Resource Service Usage Organization Policy instead of proxies to selectively allow access to individual Google Cloud APIs. The challenges related to building and maintaining a web proxy for access control to individual Google APIs are discussed in the following sections.

Shared IP address ranges used by multiple Google APIs

You can't control access to an individual Google API by a proxy or firewall rule that filters to a single IP address. Google uses a dynamic range of IP addresses for default domains. Within these IP addresses, there is not a one-to-one relationship between a dedicated IP address and a specific API.

Shared domains used by Google APIs

For some Google APIs, you can't control network access by filtering traffic on domains. Most Google APIs are reachable on endpoints which differentiate specific APIs by path and begin with a URI starting with www.googleapis.com. Certain Google APIs also use an endpoint with a dedicated subdomain. For example, the Cloud Storage API reference documents URIs in relation to the storage.googleapis.com/storage/v1 endpoint, but you could also use a URI starting with www.googleapis.com/storage/v1 to call the same API methods.

When you use multiple APIs that only have endpoints on the domain www.googleapis.com, the egress proxy cannot distinguish between APIs based solely on the domain. For example, some Google Cloud APIs like Deployment Manager, and other Google APIs, like Tag Manager or Google Play Games, are only accessible on the www.googleapis.com domain. Additionally, all Google Cloud APIs use TLS encryption by default. If you want to allow one of these APIs but block the others, your proxy would have to decrypt the request to filter on the URI path, increasing complexity.

Bottlenecks caused by proxies

If all the traffic from your VPC network to Google APIs must go through an egress proxy, the proxy could become a bottleneck. If you do use an egress proxy for traffic from your VPC network to Google APIs, we recommend that you build the proxy for high availability to avoid service disruption. Maintaining and scaling the proxy can become complex because as your organization grows, the proxy could introduce a single point of failure, latency, and reduced throughput. There might be a particular impact on operations that transfer large volumes of data.

Service-to-service exfiltration risk

A web proxy can restrict whether a Google API is reachable from your VPC network, but does not address other exfiltration paths that use the Google API. For example, an employee within your enterprise might have legitimate IAM privileges to read internal Cloud Storage buckets. With this privilege, they could read internal data and then copy that data to a public bucket. The egress proxy cannot restrict API-to-API traffic that does not originate in your VPC, or control how internet traffic reaches the public endpoints for Google Cloud APIs.

For sensitive data, a VPC Service Controls perimeter helps to mitigate this type of exfiltration. Enforcing a VPC Service Controls perimeter helps to protect resources inside the perimeter from misconfigured IAM policies, exfiltration, and compromised credentials.

Configure network controls to restrict unapproved services

When using the Restrict Resource Service Usage Organization Policy, to effectively restrict access to services, you must consider how your VPC network restricts egress traffic and exfiltration paths. The following sections describe best practices for network design to use the Restrict Resource Service Usage Organization Policy effectively.

Configure VPC Service Controls

When you're using the Restrict Resource Service Usage Organization Policy, we recommend that you also configure VPC Service Controls. By applying the Organization Policy in a project, you restrict which services can be used in that project, but the Organization Policy does not prevent services in this project from communicating with services in other projects. In comparison, VPC Service Controls lets you define a perimeter to prevent communication with services outside the perimeter.

For example, if you define an Organization Policy to allow Compute Engine and deny Cloud Storage in your project, a VM in this project couldn't create or communicate with a Cloud Storage bucket in your project. However, the VM can make requests to a Cloud Storage bucket in another project, so exfiltration with the Cloud Storage service is still possible. To block communication with Cloud Storage or other Google services outside the perimeter, you must configure a VPC Service Controls perimeter.

Use these controls together to selectively allow approved services in your environment and block a range of exfiltration paths to unapproved services.

Remove paths to the internet

If resources in your VPC network can communicate directly to the internet, there could be an alternative path to unapproved Google APIs and other services you want to block. Therefore we recommend that you only use internal IP addresses on your VMs and don’t allow egress routes through a NAT or proxy solution. The Restrict Resource Service Usage Organization Policy does not mitigate exfiltration paths to the public internet, so unapproved services could still be accessed indirectly from a server outside of your environment.

Configure a private endpoint for API access

To control API endpoints in your network, we recommend that you access Google APIs using Private Service Connect. When you configure Private Google Access to allow VMs with only internal IP to access Google APIs, this includes access to all Google APIs, including those not supported by VPC Service Controls or the Restrict Resource Service Usage Organization Policy. You can restrict Private Google Access to only supported APIs by additionally configuring Private Service Connect with the vpc-sc bundle.

For example, enabling Private Google Access allows a private network path to all Google APIs, such as Google Google Drive or Google Maps Platform. An employee might copy data to their personal Google Drive from a Compute Engine instance using the Google Drive API. You can prevent this exfiltration path by configuring Private Service Connect with the vpc-sc bundle to provide access to the same set of services supported by the restricted virtual IP (VIP) at the restricted.googleapis.com endpoint. In comparison, a broader set of Google APIs can be reached using Private Google Access when you use the Google default domains, a Private Service Connect endpoint configured with the all-apis bundle, or the private VIP (private.googleapis.com).

Alternatively, you can configure routes to restricted.googleapis.com. You might prefer to use the restricted VIP if you don't want to create a Private Service Connect endpoint for each region and each VPC network in your environment. However, we recommend the Private Service Connect approach because you can create an endpoint internal to your VPC network, compared to the restricted VIP approach which requires a route to a publicly announced endpoint.

What's next