Managing shared resources with groups and permissions

Anton Kovalsky
  • Updated

Learn how to use permissions (roles) and managed groups to control how much - and with whom - you share in Terra. Note that Terra workspace permissions determine who can incur GCP costs for an analysis. All workspace costs are billed through the Terra Billing project you assign to  th workspace when you create it.   

Controlling access to resources (data and analysis tools in workspaces, and 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 (Google Cloud Billing account, Terra Billing project, and workspace) in boxes in the diagram below. Blue boxes are Google resources and grey are Terra resources. Read on for more details about what roles and permissions of each resource allow. 


Workspace permissions/roles

Workspace permissions control who can analyze, access, and share data.


When you share a workspace, you grant each collaborator 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 in the workspace Billing project. 


Workspace (not billing) permissions determine who can incur GCP costs


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
When you create a workspace, Terra automatically makes you the "owner". Owners
control who can share the workspace, access data and accrue costs (run workflows or
interactive analyses) by assigning roles (permission) to collaborators. 

Workspace roles/permission examples (expand for list view)
All roles that enable users to accrue costs are noted in red
  • Owner (can incur storage, compute and query 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 run a workflow or start a Cloud Environment)
    Able to launch workflows and interactive analyses (notebooks). 
  • Share-writer (can enable others to incurs costs - also, see Writer, above)
    Able to grant others write access. 
  • Share-reader
    Able to grant others read access. 
  Owner Writer Reader Can
Can edit workspace
documentation, data tables


 X  depends 
Can access data in
the workspace bucket


Can give others access


depends  -- depends

Can run workflows and
interactive analyses



Can store data




Billing permissions/roles

Roles on a Cloud Billing account or Terra Billing project determine who can create billing projects and workspaces (respectively).

Billing resources in Terra include Google Cloud Billing accounts and Terra Billing projects. Access to billing (i.e. accounts and projects) allows you to create resources (i.e. Terra billing projects and workspaces, respectively). Google Cloud Billing account owners, admins, and users can also access workflow spend reporting in Terra, detailed cost breakdowns in GCP and set budget alerts (in GCP console).


Billing project roles don't directly affect who can work in a workspace


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). Once someone creates a workspace using a Terra Billing  project, they will be able to accrue costs (charged to that Terra Billing project)

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. Note that a workspace creator is the owner by default. 


Google Cloud Billing account and Terra Billing project roles

  • Administrator - can see and manage all billing aspects
  • Viewer - can view billing account information 
  • User - can access Billing account (to create Terra Billing projects)

Access cost breakdown

Create Billing projects


Store and
analyze data

Cloud Billing account admin, owner, user

(in GCP console)

(in Terra UI)

(in Terra UI)

Depends on
workspace role

Terra Billing project owner or user



Depends on
workspace role




Workspace creators are owners by default


When you create a workspace, you are automatically the owner. Owners
control who can share the workspace, access data, and accrue costs (run workflows or
interactive analyses) by assigning roles (permission) to collaborators. 


Example cases (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 need to share the workspace and give them permission. 

  • Removing collaborators from a Google Cloud Billing account or Terra Billing project means they cannot create Terra 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.


Best practices for 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.

Group roles versus resource permissions


Permissions for managed groups are not the same as permissions for other resources. If a
group is given access to a workspace, the
workspace owner controls the role of the group
with respect to the workspace (i.e. reader or writer), but the
group's owner controls the
role of the user in the group.

For example, if a group has the role of writer (not owner) in a workspace, even group
admins will only have writer access. The admins would need to be given writer access individually. 


Create your team Terra group in four steps

1. Go to your Groups page (Main menu > Groups from the top left of any page in Terra).

2. In the Create a New Group card, click on the blue "+" icon.

3. Enter your human-friendly team group name and click the Create Group button.

4. You can share resources with the group just like with an individual. Use the email listed ( and assign it a role on the resource. To add more people to the group, just click on the group name and click + Add User. 

Note that the group admin can change who is in the group at any time in Terra. 

Permissions and groups and access to resources and billing - a lab scenario

Follow the story diagram below to see how permissions, groups and billing might affect access to resources in a cartoon lab scenario:
  1. The head of a research laboratory (User #1) creates a billing project - they are the "Owner" of the billing project
  2. 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.
  3. 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.
  4. 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?
  5. 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).

  6. 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.
  7. The the group (users #4, 5 and 6) now has “Reader” permission.


Was this article helpful?

2 out of 4 found this helpful

Have more questions? Submit a request



Please sign in to leave a comment.