Authorized views

This document describes how to create authorized views and authorized materialized views in BigQuery.

Overview

As a data administrator, you can create an authorized view to share a subset of data in a dataset to specific users and groups (principals). Principals can view the data you share and run queries on it, but they can't access the source dataset directly.

View types

A logical view is the default view type for BigQuery, and a materialized view is a precomputed view that periodically caches the results of a query for increased performance and efficiency.

An authorized view for a logical view is called an authorized view, but an authorized view for a materialized view is called an authorized materialized view.

If a logical view relies on a large or computationally expensive query, then you can create a materialized view instead. However, querying only a subset of your data or using other techniques can often improve performance without the need to create a materialized view.

For more information, see the following resources:

• Introduction to logical views
• Introduction to materialized views

High-level steps for creating authorized views

To create and share a view, review these high-level steps, which are the same for authorized logical views and authorized materialized views.

• Create a dataset to contain your source data.
• Run a query to load data into a destination table in the source dataset.
• Create a dataset to contain your authorized view.
• Create an authorized view from a SQL query that restricts the columns that your data analysts can see in the query results.
• Grant your data analysts permission to run query jobs.
• Grant your data analysts access to the dataset that contains the authorized view.
• Grant the authorized view access to the source dataset.

Alternatives

Although authorized views are flexible and scalable, one of the following methods might better apply to your use case:

• Set row-level policies on a table.
• Set column-level policies on a table.
• Store data in a separate table.
• Share all views in a dataset (authorized datasets).

Use row-level or column-level security, or separate tables

By setting row-level access policies on a table, or by creating a separate table to hold sensitive data, a data administrator can restrict a user's ability to view that data. Storing data in a separate table isolates the data and removes the ability to see how many rows exist in the table.

In addition, by creating and applying policy tags, a data administrator can restrict the user's ability to view columns in a table.

Storing data in a separate table is the most secure but least flexible method. Setting row-level policies is flexible and secure, while sharing authorized views is flexible and provides the best performance.

To compare these methods in detail, see the following resources: