Using permissions and groups to manage shared resources (billing, data, and workspaces)
Use permissions (roles) and managed groups to control how much - and with whom - you share in Terra.
Contents
Controlling access to data, workspaces, and billing
- Workspace permissions - who can analyze, access and share resources
- Billing permissions - who can create Billing projects and workspaces
- Managed groups - Enabling large sets of users to access resources
Evolution of permissions - a lab scenario
Controlling access to resources (data, workspaces, billing)
If you work in teams, you're probably familiar with the idea of using permissions or roles to control what collaborators can do with shared resources (such as datasets or analysis tools). Roles are granted by the owner (or other person with the right permissions). Typical roles include "owner", "administrator" and "user".
In Terra, you can assign roles for each resource (GCP Billing account, Terra Billing project, and workspace) in gray boxes in the diagram below. Read on for more details about what roles and permissions of each resource allow.
Workspace permissions/roles - who can analyze, access, and share data
Workspace permissions control who can perform what operations in a workspace. When you share a workspace, you grant each person a role, or permission level, in the share screen.
Examples of workspace roles and their permitted activities
| Owner | Writer | Reader | Can compute |
|
| Can edit workspace documentation, data tables |
✔ |
✔ |
X | depends |
| Can access data in the workspace bucket |
✔ |
✔ |
✔ |
X |
| Can give others access |
✔ |
depends | -- | depends |
|
Can run workflows and interactive analyses |
✔ |
depends |
X |
✔ |
|
Can store data |
✔ |
✔ |
X |
depends |
Note that whether a person can perform operations that have a GCP cost depends on their workspace role (not their Billing project role).
|
|
|---|---|
|
Workspace roles that allow users to incur costs include "Writer" and "Owner" and anyone Note that workspace creators are owners, by default |
Workspace roles/permissions
- Owner (can incur costs) - may add/remove users (grant access), lock workspace, etc.
- Writer (can incur storage costs by adding data to the workspace bucket) - may write to/add tables, workflow configs, etc.
- Reader - may read tables, method configs, etc.
- Can-compute (can incur compute costs) - able to launch workflows and interactive analyses (notebooks).
- Share-writer (can enable others to incurs costs - see Writer, above) - able to grant others write access.
- Share-reader - able to grant others read access.
Billing permissions/roles - who can create billing projects and workspaces
Billing resources in Terra include GCP Billing accounts and Terra Billing projects. Access to billing (i.e. GCP Billing accounts and Terra billing projects) allows you to create resources (i.e. Terra billing accounts and workspaces). GCP Billing account owners, admins and users can also access detailed cost breakdowns in GCP.
Billing account (GCP) and billing project (Terra) roles
- Administrator - can see and manage all billing aspects
- Viewer - can view billing account information
- User - can access Billing account
|
|
|---|---|
|
Workspace permissions are what determine who can incur cost in a workspace. Workspace Billing project roles determines whether you can create resources like projects or |
|
Can access cost breakdown |
Can create Billing projects |
Can create workspaces |
Can store and analyze data |
|
|
Billing account admin, owner, user |
✔in GCP console |
✔in Terra UI |
✔in Terra UI |
Depends on workspace role |
|
Billing project admin, owner, user |
x |
x |
✔ |
Depends on workspace role |
Workspace creators are owners by default |
|
|---|---|
|
When you create a workspace, Terra automatically makes you the "owner". Owners |
Unexpected example cases
- A Billing project user won't have access to a workspace created by a collaborator under the same Billing project without the right workspace permission. The workspace owner would share the workspace and give them permission.
- Removing a user from a Billing account or Billing project means they cannot create billing projects or workspaces (respectively). It does not impact their ability to accrue charges in a workspace where they already have "can-compute" permission.
Managed groups - Enabling many users to access the same resources
A collaborative team may have many team members, numerous workspaces and even separate billing projects. To streamline resource management, especially since teams often change, owners can assign permissions (roles) to a managed group as well as to an individual. A managed group could include everyone in a research team, for example, who might need access to the same workspace or billing project.
Managing changing teams with groups
Groups are especially useful when team members change. Owners can simply adjust the group membership in the Groups page of Terra. This automatically updates the users for every resource shared with the group. This way, Owners don't have to update every individual workspace, billing project etc.
Roles for managed groups
- Member - any individual in the group. When any form of access is granted to a group, the members include all who have that access.
- Admin - may add or remove members or other admins to or from the group. Admins are also members of the group.
- Admin-notifier - users who are allowed to send notifications to the admins of a group. When a group is created, this access policy is set to public - meaning all users are able to request access to a group.
|
|
|---|---|
|
Permissions for managed groups are not the same as permissions for other resources. If a For example, if a group has the role of "writer" (not owner) in a workspace, even group |
Evolution of permissions and groups and access to resources and billing - a lab scenario
- The head of a research laboratory (User #1) creates a billing project - they are the "Owner" of the billing project
- User #1 assigns the role of “workspace creator” to their post-doctoral fellows (User #2) , charging them with the task of creating a fresh workspace to be shared with potential collaborators. The workspace will include shared data resources uploaded to the workspace Google bucket.
- The post doc creates the workspace (they are automatically the Owner of the workspace), adds some content, and then invites another coworker (User #3) to help edit the content - giving them “writer can-compute” permission in the workspace.
- User #3 is can now edit and run code in the workspace, but cannot give other new users access. Can you guess what role they have with respect to the workspace resource?
- In the meantime, a researcher from an unrelated group (User #4) - who wants to introduce a team of students to Terra - creates a managed group (they’re the "Owner" of the group).
- In order for the students (User #5, User #6) to access the workspace, User #2 (workspace owner) must give the group created by User #4 reader permission for that workspace. All the group's members, including the group's owner, will have "read" permissions on the workspace.
- The the group (users #4, 5 and 6) now has “Reader” permission.
Comments
0 comments
Please sign in to leave a comment.