GCP Console vs VPC-SC: can you access it? It Depends
TL/DR
You enforced your VPC SC perimeter, now the Google Cloud Web Console doesn’t work, what can and should you do?
This article and the associated content has been co-developed with Carlo Marini
Context
VPC SC is a Google Cloud Platform (GCP) service that prevents accidental or targeted data exfiltration, by external entities or insider entities, from Google Cloud services such as Cloud Storage or BigQuery — this is by far is the main use case of VPC SC.
VPC SC works with perimeters: the user defines boundaries (perimeters) that include the projects (or VPCs) to be protected. Once the perimeter is in place, only the projects/VPCs included in that perimeter can “interact with each other”.
VPC SC perimeter preventing data to be moved outside of the perimeter
In the example above the perimeter prevents data exfiltration outside of the projects belonging to the perimeters (project 1 and 2).
NOTE: The principal that is invoking the API might have the right to execute the API call: it is VPC SC that is blocking the insertion operation, not the IAM!
The problem
What happens with the GCP console? There are a few facts to take into account:
1. GCP Console lives on the Internet and cannot be accessed privately
2. GCP Console isn’t part of a users’s GCP project and can therefore not be included in a VPC SC perimeter
3. GCP Console will invoke several GCP API calls in consequence of a user’s click (for example, upload an object into a bucket)
For the above reasons (at least), as soon as VPC SC is in place the GCP Console might become fairly unusable, because it can not issue API requests on behalf of the user (for the APIs that are protected by the perimeter).
VPC SC perimeter preventing GCP Console to execute API calls within GCP
As represented above:
“Because the Google Cloud console is only accessible over the internet, it is treated as outside of service perimeters. When you apply a service perimeter, the Google Cloud console interface for the services that you protected may become partially or fully inaccessible….”
Source: https://cloud.google.com/vpc-service-controls/docs/supported-products?hl=en#console
Example: Let’s say you have an enforced perimeter with “project acme” included and storage.googleapis.com protected. If you try to access a bucket from the console, you will get the following:
The violation (“NO_MATCHING_ACCESS_LEVEL”) is included in the Audit log:
Important notice
Before describing possible solutions, it is worth mentioning that it, in fact, is working as designed: VPC SC is used to prevent access from the internet. Therefore, it is important to first evaluate the GCP access patterns within the organization and make an informed decision if it would not be wiser to stop performing at least specific operations from the console whatsoever.
Solutions
If, however, the console access is indeed necessary, the trick is to authorize access from outside of the perimeter:
Solution 1: Access Level based on source IPs (the ranges through which clients exit the corporate network to the internet). This is by far the most viable option for clients belonging to a corporate/enterprise network where the Corporate Nat IPs are known. In the figure below the Client resides on a generic “on premises” datacenter and the access to internet is leveraging a corporate proxy/NAT, so that we know what is the IP to be used in the access level.
This configuration can be generalized: the trick is to know what is the source IP to the internet in order to create the proper access level. For example we might think of a jump server/proxy in a known location: the client’s traffic to the GCP Console will transit to that bastion/proxy before reaching the console.
Access level allows users to consume the API through GCP Console
Solution 2: Context aware Access based on device (Google Beyond Corp approach). This approach uses a combination of device attributes, such as the user’s location and the device’s security posture, to determine whether a user is allowed to access the console. This is a secure and scalable approach, but it requires a Google Beyond Corp enterprise license.
Solution 3 (NOT RECOMMENDED): Access level based on users (NOT groups) who need to access the console. This approach uses an allowlist of individual users who are allowed to access the console.
NOTE: There are two important drawbacks with this approach: it can be difficult to manage high numbers of users, and every user has access to the whole perimeter, which is not optimal from security perspective.
Conclusion
Usage of GCP Console is one of the first use cases that you need to address when considering VPC SC due to the nature of the GCP Console itself that resides on the internet.
A proper Context Access Level must be configured to allow the console to consume the protected APIs — if the usage is indeed necessary.