Service Perimeter for project with gmail users

Question

Our goal is to restrict a subset of our GCS buckets for use by a range of IP addresses.

We have several GCP projects in a university lab tied to a common billing account, where people generally use their gmail address for interacting with GCP resources. We believe we need to setup a service perimeter around our buckets using VPC Service Controls.

VPC Service Controls seem to require an organization. Creating an organization seems to require GSuite or Cloud Identity. Both of these options seem to require accounts to be setup on a specific domain. I do not want to ask people to create additional accounts, and migrate to using them.

Is there a path forward to having a collection of gmail users implement a service perimeter? Or is there another way to get IP-address restriction on GCS buckets?

Answer 1

I hear two things ... I hear restricting access to GCS buckets by the requestor's source IP address and I hear restricting access to GCS buckets by the user's identity (gmail address). These are two distinct stories.

To restrict access by IP address, we can use VPC Service Controls and access levels.

See:

• Creating an access level

To restrict by user, the same story as above can also be employed. However, it strikes me that GCS is resource based and as such, is protected by IAM security. This means that GCS resources can also be protected by assigning permissions to individual users or groups of users.

Answer 2

According to the Granting access to an organization documentation, you can actually grant access to an organization’s resources by granting roles to Google Account email.

However, just to confirm this, I went ahead and did some tests, and I was able to add my gmail account to a project on a different organization domain with no problems.

Also, as mentioned in the Can I use Google groups with Cloud IAM? documentation, you can add these users to a Google Group, and use it to easily manage their permissions.

When adding the group to the IAM section, you will add the group’s email address, so the domain will also be different than the organization domain. This process is pretty straight forward, but I shared a few screenshots on this post, in case you need help with that.

Conclusion:

So the ideal solution would still be to use VPC Service Controls with Access Levels, but with the addition of controlling user’s access to specific resources using IAM roles.

The steps to achieve this setup would be:

1 - Create an Access Level, as explained in the Limit access on a corporate network documentation.

2 - Create the VPC Service Perimeter with the new Access Level.

3 - Grant the desired IAM roles to the user’s in the IAM section, here you could grant the roles to a Google Group instead if you prefer.

Answer 3

To use VPC Service Controls (which allows you to restrict access to Google Cloud Storage buckets by IP address) you will require an organization. For managing resources for projects in that organization any Google identity (gmail, cloud identity, G Suite) is valid. Combine the two and you have your solution!