BigQuery Authorized Views for Access Control

BigQuery authorized views are a security mechanism that allows a view (a saved SQL query) in one dataset to access data from another dataset, even if the users running the view do not have direct permissions on the source dataset. The view is "authorized" by the source dataset's owner, meaning the source dataset explicitly grants the view's identity (its Google Cloud resource name) permission to query its tables. This enables a data owner to share a controlled subset of data without granting underlying table access.

In enterprise environments, data is often stored in centralized datasets managed by a data governance team. Different teams need access to different slices of that data. For example, the marketing team should see only customer names and email addresses, not purchase history or credit card numbers. Without authorized views, you would have to either grant the marketing team direct access to the source tables (violating least privilege) or create separate copies of the data (wasting storage and risking staleness). Authorized views solve this by allowing the data owner to define a view that filters and transforms data, then authorize that view to access the source dataset. Users query the view as if it were a regular table, but they never have permissions on the underlying tables.

Authorized views rely on BigQuery's identity-based access control. Every BigQuery resource (dataset, table, view) has a unique Google Cloud resource name, such as projects/myproject/datasets/mydataset/tables/mytable. When a user runs a query against a view, BigQuery performs authorization checks at two levels:

The key insight: the user's identity is NOT checked against the source dataset. Only the view's identity is checked. This is why authorized views are a delegation mechanism — the view acts as a proxy, and the source dataset trusts the view, not the end user.

To set up an authorized view, you need:

Configuration steps:

1. Create the view in the view dataset:

CREATE VIEW myproject.viewdataset.safe_customers AS
   SELECT name, email
   FROM myproject.sourcedataset.customers;

2. Grant the view access to the source dataset using the bq command-line tool or the Cloud Console:

bq show --format=prettyjson myproject:sourcedataset > dataset.json
   # Edit dataset.json to add the view's resource name under 'access' array with role 'READER'
   bq update --source dataset.json myproject:sourcedataset

Or using bq with the --authorized_view flag (available in newer versions):

bq update --authorized_view myproject:viewdataset.safe_customers myproject:sourcedataset

BigQuery access control uses a combination of IAM roles and dataset-level ACLs (legacy). Authorized views are a dataset-level ACL feature. When you add an authorized view, you are essentially adding an entry to the dataset's access control list that grants the view's identity a READER role (which includes bigquery.tables.getData). IAM roles on the source dataset (e.g., roles/bigquery.dataViewer) are separate — they grant access to individual users or groups. Authorized views bypass those IAM checks for the view's identity only.

To verify an authorized view is set up correctly:

- List authorized views on a dataset:

bq show --format=prettyjson myproject:sourcedataset | jq '.access[] | select(.view)'

- Test access as an end user:

bq query --use_legacy_sql=false 'SELECT * FROM myproject.viewdataset.safe_customers LIMIT 10'

If the view is authorized, this should return data. If not, you'll get an access denied error.

Authorized views add minimal overhead because the authorization check is a simple ACL lookup. The view's SQL query is executed as if the view's identity is running it, so performance depends on the query complexity and data size. Caching and query optimization work normally. However, if the view is used by many users, the view's identity may hit BigQuery's quota for concurrent queries (default 100 concurrent queries per project, but adjustable).

In a financial services company, the data governance team manages a BigQuery dataset containing all transaction records, including customer PII (names, addresses, SSNs) and financial details (account balances, transaction amounts). The fraud detection team needs access to transaction amounts and timestamps but must never see PII. The data governance team creates a view named fraud_transactions in a separate dataset fraud_views, selecting only transaction_id, amount, timestamp, and merchant_category. They authorize this view on the source dataset transactions_db. The fraud team is granted bigquery.dataViewer on fraud_views. This setup ensures that even if a fraud analyst accidentally writes a query that joins with PII tables, the view's scope prevents access. In production, this pattern scales to hundreds of views across dozens of datasets. A common issue occurs when a view joins tables from multiple source datasets — each source dataset must authorize the view individually. If an engineer forgets to authorize one dataset, the query fails with a cryptic permission error. Misconfiguration often arises when using the Cloud Console: the authorized view entry must exactly match the view's resource name, including case. A common mistake is copying the view ID from the URL, which may include the project ID twice or have incorrect formatting. Performance is generally not impacted, but if the view uses complex SQL (e.g., multiple joins, subqueries), the query execution time increases. The team monitors query performance using BigQuery's INFORMATION_SCHEMA.JOBS_BY_PROJECT. Another enterprise scenario is a healthcare provider that needs to share de-identified patient data with researchers. The view filters out PHI columns and applies a row-level policy to limit data to patients who have consented. Authorized views combined with row-level security provide a powerful defense-in-depth strategy. The biggest operational risk is that authorized views do not cascade: if the view itself uses another view, that second view must also be authorized. This can lead to a chain of authorizations that is hard to manage. The team maintains a documentation table listing all authorized views and their source datasets, updated via Terraform scripts that manage the authorizations as code.