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. Note that in Terra, it is workspace permissions that determine who can incur GCP costs. All workspace costs are billed through the Terra Billing project associated with the workspace.
Contents
Controlling access to resources (data, workspaces, and billing)
- Workspace permissions (i.e. who can analyze, access and share resources)
- Billing permissions (i.e. 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)
You may already be familiar with the idea of using permissions (aka "roles") to control what collaborators can do with shared resources (such as datasets or analysis tools). Roles and permissions 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 specify who can analyze, access, and share data
 |
When you share a workspace, you grant each person a role, or permission level, in the share screen (screenshot at left). Note that collaborators with can-compute access can incur costs, even if they are not included in the billing project. |
|
|
|---|---|
|
Workspace roles that allow users to incur costs include "Writer" and "Owner" and anyone with "Can-compute" permission. Note that workspace creators are owners, by default |
Workspace roles/permission examples (expand for list view)
- 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.
| 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 |
✔ |
depends |
X |
✔ |
|
Can store data |
✔ |
✔ |
X |
depends |
Billing permissions/roles determine 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 project roles determine whether you can create resources like projects or workspaces. Note that the creator is the initial owner, by default (but this can be modified). Workspace permissions are what determine who can incur cost in a workspace. Workspace permissions can be very granular. Workspace owners can grant roles including "can-compute" or "can share" as well as the traditional "Owner," "Reader," and "Writer" roles. |
GCP Billing account and Terra billing project roles (click to expand)
- Administrator - can see and manage all billing aspects
- Viewer - can view billing account information
- User - can access Billing account
|
Access cost breakdown |
Create Billing projects |
Create |
Store and |
|
|
Billing account admin, owner, user |
✔ (in GCP console) |
✔ (in Terra UI) |
✔ (in Terra UI) |
Depends on |
|
Billing project admin, owner, user |
x |
x |
✔ |
Depends on |
Workspace creators are owners by default |
|
|---|---|
|
When you create a workspace, Terra automatically makes you the "owner". Owners |
Example cases (expand for some unintuitive billing permissions scenarios)
- 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.