Access sharing best practices

Purpose: This document provides tips for granting access on resources to Workbench users.

Introduction

The ability to grant access to users on cloud resources outside of Workbench, such as Cloud Storage buckets, BigQuery datasets, and Artifact Registry repositories, is a powerful capability to make both data and tools available without duplicating durable storage. This article provides a technical overview of several components and best practices for you to follow.

Use Workbench groups to grant access

If you need to grant access to data living in "external" non-Workbench projects (e.g., referenced resources), use Workbench groups rather than the user profile, workspace service account, or proxy group.

It's important to understand the differences and the expected behaviors of user profiles, workspace service accounts, proxy groups, and Workbench groups:

A Workbench user profile is also known as a Workbench account. A profile is associated with an individual user and their individual Google account.

A workspace service account is a Google service account created in each of the user's Cloud projects in Workbench. In Workbench, a Cloud project is created for each workspace. Therefore, each Workbench workspace will have its own workspace service account for each user with whom the workspace is shared.

In Workbench apps, Google Compute Engine virtual machines will use workspace service account credentials to access Cloud resources. A workspace service account email address will start with pet- (i.e., pet-<123456789>@<project-id-1>.iam.gserviceaccount.com).

A proxy group is a Google Group that's made up of a user account and each of the user's workspace service accounts. A proxy group's email address will start with PROXY and have the verily-bvdp.com domain (i.e., PROXY_123456789@verily-bvdp.com).

Workbench groups are a list of Workbench profiles (or users). Each Workbench group has a mirrored Google Group. This Google Group will consist of proxy groups of each Workbench user in the Workbench group. In the diagram below, you can see how the my-researchers Workbench group has a mirrored Google Group that consists of the two users' proxy groups.

We recommend you grant access to a Workbench group, even if the group is made up of only one user. By doing so, you can use naming that you recognize (rather than the cryptic proxy group name) to grant access to a user's proxy group, workspace service accounts, and user account.

For example, granting access to a Cloud resource (like a Cloud Storage bucket) to a Workbench group will allow a user in that group to access the resource with their end user credentials (from their laptop/workstation), as well as their workspace service accounts (cloud environment VMs and workflow VMs).

If your Workbench user ID is user@example.com, you would do the following:

1. Create a Workbench group if one doesn't already exist. As an example, we'll create a Workbench group called user_at_example_dot_com. This Workbench group will have an ID of user_at_example_dot_com@verily-bvdp.com.
2. Add user@example.com to the user_at_example_dot_com Workbench group.
3. Grant access on your resources to the Workbench group, user_at_example_dot_com@verily-bvdp.com.

Why shouldn't I grant access to a user account, workspace service account, or proxy group?

We don't recommend granting direct access to anything other than a Workbench group for several reasons:

• Workspace service accounts and proxy group IDs are not human-readable so it's not intuitive to whom the account/ID belongs. For example, workspace service accounts will look something like:

  pet-<long-number>@<project-id-1>.iam.gserviceaccount.com

  while proxy group accounts will look something like:

  PROXY_<long-number>@verily-bvdp.com.

• Granting access to an end user account does not provide access in Workbench.

• It's harder to keep track of access if it's granted on an individual level.

Grant access at a data level

You can grant access at a project level, but we don't recommend it since it can lead to oversharing. In addition, you won't be able to create new buckets or datasets in the project without end users being able to see or access them. Therefore, it's best practice to grant access at a data level (i.e., buckets, datasets).

Align workspace grants and data grants

It's not a hard requirement to align your workspace and data access grants, but doing so could simplify your administration. For example, it could be helpful to define Workbench groups that would be used for both sharing a workspace and giving access to referenced resources.