Also read - File Formats for loading data into BigQuery

This post discusses a list of helpful BigQuery roles, in order of decreasing privileges.

  • BigQuery Admin User: Users in this role will have the highest level of access to BigQuery. Exercise caution when adding users to this role. Usually it is granted only to db admins and deployment team members, not to developers or testers in the project.
  • BigQuery Data Owner: Users in this role have all the permissions that are part of Data Editor and can delete datasets in the project. Users in this role cannot query data in BigQuery nor can they import/export data in BigQuery.
  • BigQuery Data Editor: Users in this role have all the permissions that are part of Data Viewer and also have permissions to create a new dataset, create a new table, and delete tables. The users in this role cannot query data in BigQuery nor can they import/export data in BigQuery.
  • BigQuery User: Users in this role are similar to BigQuery Data Viewer but they can run queries that show the data and cannot do import/export. Users can save queries under their account. In production projects, a developer is usually granted BigQuery Data Viewer and BigQuery User permission so that they can query and verify the data in production without changing any tables or data in the tables.
  • BigQuery Job User: Users in this role can run queries and export/import data in BigQuery. In development projects, the developers are usually granted BigQuery Data Editor and BigQuery Job User permissions to run queries and import/export data into the tables in the project.
  • BigQuery Data Viewer: This is the most basic level of permission that can be granted to users. Users who are granted this permission can only see the projects, datasets in the project, tables in the project, and information about the tables such as schema, number of rows, or when it was created and modified. Users can see sample rows from the table using the preview option. Users who have been assigned this role cannot execute any queries. This role is mostly assigned to users who review the objects in BigQuery.

What if you need to further control access? E.g. individual table or row level access?

Here are some additional options - Authorized Views, Row Level Policies and of course, isolated Tables

Authorized
views		 Vulnerable to carefully crafted queries, query duration, and other types of side-channel attack. When flexibility and performance are most important.

Example: sharing data within the same work group.
Row-level access policies Vulnerable to carefully crafted queries and query duration side-channel attacks. When it is convenient to have all users query the same table. For instance, when everyone shares the same dashboard, but some users have access to more data.

To provide additional security over views.

Example: sharing table slices within your organization.
Isolated, Separate tables Complete isolation. When isolation is paramount. For instance, when the total number of rows must be secret.

Example: sharing data outside your organization, such as with third-party partners and vendors.

Summary

BigQuery roles are easy to work with. Always use the least privilege principle when working with BigQuery roles.