A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://developers.google.com/bigquery/docs/dataset-access-controls below:

Control access to resources with IAM | BigQuery

Skip to main content

Stay organized with collections Save and categorize content based on your preferences.

Control access to resources with IAM

This document describes how to view, grant, and revoke access controls for BigQuery datasets and for the resources within datasets: tables, views, and routines. Although models are also dataset-level resources, you cannot grant access to individual models using IAM roles.

You can grant access to Google Cloud resources by using allow policies, also known as Identity and Access Management (IAM) policies, which are attached to resources. You can attach only one allow policy to each resource. The allow policy controls access to the resource itself, as well as any descendants of that resource that inherit the allow policy.

For more information on allow policies, see Policy structure in the IAM documentation.

This document assumes familiarity with the Identity and Access Management (IAM) in Google Cloud.

Limitations Before you begin

Grant Identity and Access Management (IAM) roles that give users the necessary permissions to perform each task in this document.

Required roles

To get the permissions that you need to modify IAM policies for resources, ask your administrator to grant you the BigQuery Data Owner (roles/bigquery.dataOwner) IAM role on the project. For more information about granting roles, see Manage access to projects, folders, and organizations.

This predefined role contains the permissions required to modify IAM policies for resources. To see the exact permissions that are required, expand the Required permissions section:

Required permissions

The following permissions are required to modify IAM policies for resources:

You might also be able to get these permissions with custom roles or other predefined roles.

Work with dataset access controls

You can provide access to a dataset by granting an IAM principal a predefined or custom role that determines what the principal can do with the dataset. This is also known as attaching an allow policy to a resource. After granting access, you can view the dataset's access controls, and you can revoke access to the dataset.

Grant access to a dataset

You can't grant access to a dataset when you create it using the BigQuery web UI or the bq command-line tool. You must create the dataset first and then grant access to it. The API lets you grant access during dataset creation by calling the datasets.insert method with a defined dataset resource.

A project is the parent resource for a dataset, and a dataset is the parent resource for tables and views, routines, and models. When you grant a role at the project level, the role and its permissions are inherited by the dataset and by the dataset's resources. Similarly, when you grant a role at the dataset level, the role and its permissions are inherited by the resources within the dataset.

You can provide access to a dataset by granting an IAM role permission to access the dataset or by conditionally granting access using an IAM condition. For more information on granting conditional access, see Control access with IAM Conditions.

Note: Granting access to a dataset doesn't automatically list it in the Explorer pane. To view a project in the Explorer pane, see Star a project.

To grant an IAM role access to a dataset without using conditions, select one of the following options:

Console

  1. Go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer pane, expand your project and select a dataset to share.

  3. Click person_add Sharing > Permissions.

  4. Click person_add Add principal.

  5. In the New principals field, enter a principal.

  6. In the Select a role list, select a predefined role or a custom role.

  7. Click Save.

  8. To return to the dataset info, click Close.

SQL

To grant principals access to datasets, use the GRANT DCL statement:

  1. In the Google Cloud console, go to the BigQuery page.

    Go to BigQuery

  2. In the query editor, enter the following statement:

    GRANT `ROLE_LIST`
ON SCHEMA RESOURCE_NAME
TO "USER_LIST"

    Replace the following:

  3. Click play_circle Run.

For more information about how to run queries, see Run an interactive query.

The following example grants the BigQuery Data Viewer role to myDataset:

GRANT `roles/bigquery.dataViewer`
ON SCHEMA `myProject`.myDataset
TO "user:user@example.com", "user:user2@example.com"
bq

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To write the existing dataset information (including access controls) to a JSON file, use the bq show command:

    bq show \
    --format=prettyjson \
    PROJECT_ID:DATASET > PATH_TO_FILE

    Replace the following:

  3. Make changes to the access section of the JSON file. You can add to any of the specialGroup entries: projectOwners, projectWriters, projectReaders, and allAuthenticatedUsers. You can also add any of the following: userByEmail, groupByEmail, and domain.

    For example, the access section of a dataset's JSON file would look like the following:

    {
 "access": [
  {
   "role": "READER",
   "specialGroup": "projectReaders"
  },
  {
   "role": "WRITER",
   "specialGroup": "projectWriters"
  },
  {
   "role": "OWNER",
   "specialGroup": "projectOwners"
  },
  {
   "role": "READER",
   "specialGroup": "allAuthenticatedUsers"
  },
  {
   "role": "READER",
   "domain": "domain_name"
  },
  {
   "role": "WRITER",
   "userByEmail": "user_email"
  },
  {
   "role": "READER",
   "groupByEmail": "group_email"
  }
 ],
 ...
}

  4. When your edits are complete, use the bq update command and include the JSON file using the --source flag. If the dataset is in a project other than your default project, add the project ID to the dataset name in the following format: PROJECT_ID:DATASET.

    Caution: When you apply the JSON file that contains the access controls, the existing access controls are overwritten. 
      bq update 
    
  --source PATH_TO_FILE 
    
  PROJECT_ID:DATASET

  5. To verify your access control changes, use the bq show command again without writing the information to a file:

    bq show --format=prettyjson PROJECT_ID:DATASET
Terraform

Use the google_bigquery_dataset_iam resources to update access to a dataset.

Important: The different resources provided by google_bigquery_dataset_iam can conflict with each other as well as with the google_bigquery_dataset_access resource. Read the google_bigquery_dataset_iam documentation carefully before making access control changes using Terraform.

Set the access policy for a dataset

The following example shows how to use the google_bigquery_dataset_iam_policy resource to set the IAM policy for the mydataset dataset. This replaces any existing policy already attached to the dataset:

# This file sets the IAM policy for the dataset created by
# https://github.com/terraform-google-modules/terraform-docs-samples/blob/main/bigquery/bigquery_create_dataset/main.tf.
# You must place it in the same local directory as that main.tf file,
# and you must have already applied that main.tf file to create
# the "default" dataset resource with a dataset_id of "mydataset".

data "google_iam_policy" "iam_policy" {
  binding {
    role = "roles/bigquery.admin"
    members = [
      "user:user@example.com",
    ]
  }
  binding {
    role = "roles/bigquery.dataOwner"
    members = [
      "group:data.admin@example.com",
    ]
  }
  binding {
    role = "roles/bigquery.dataEditor"
    members = [
      "serviceAccount:bqcx-1234567891011-12a3@gcp-sa-bigquery-condel.iam.gserviceaccount.com",
    ]
  }
}

resource "google_bigquery_dataset_iam_policy" "dataset_iam_policy" {
  dataset_id  = google_bigquery_dataset.default.dataset_id
  policy_data = data.google_iam_policy.iam_policy.policy_data
}

Set role membership for a dataset

The following example shows how to use the google_bigquery_dataset_iam_binding resource to set membership in a given role for the mydataset dataset. This replaces any existing membership in that role. Other roles within the IAM policy for the dataset are preserved:

# This file sets membership in an IAM role for the dataset created by
# https://github.com/terraform-google-modules/terraform-docs-samples/blob/main/bigquery/bigquery_create_dataset/main.tf.
# You must place it in the same local directory as that main.tf file,
# and you must have already applied that main.tf file to create
# the "default" dataset resource with a dataset_id of "mydataset".

resource "google_bigquery_dataset_iam_binding" "dataset_iam_binding" {
  dataset_id = google_bigquery_dataset.default.dataset_id
  role       = "roles/bigquery.jobUser"

  members = [
    "user:user@example.com",
    "group:group@example.com"
  ]
}

Set role membership for a single principal

The following example shows how to use the google_bigquery_dataset_iam_member resource to update the IAM policy for the mydataset dataset to grant a role to one principal. Updating this IAM policy does not affect access for any other principals that have been granted that role for the dataset.

# This file adds a member to an IAM role for the dataset created by
# https://github.com/terraform-google-modules/terraform-docs-samples/blob/main/bigquery/bigquery_create_dataset/main.tf.
# You must place it in the same local directory as that main.tf file,
# and you must have already applied that main.tf file to create
# the "default" dataset resource with a dataset_id of "mydataset".

resource "google_bigquery_dataset_iam_member" "dataset_iam_member" {
  dataset_id = google_bigquery_dataset.default.dataset_id
  role       = "roles/bigquery.user"
  member     = "user:user@example.com"
}

To apply your Terraform configuration in a Google Cloud project, complete the steps in the following sections.

Prepare Cloud Shell
  1. Launch Cloud Shell.

  2. Set the default Google Cloud project where you want to apply your Terraform configurations.

    You only need to run this command once per project, and you can run it in any directory.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Environment variables are overridden if you set explicit values in the Terraform configuration file.

Prepare the directory

Each Terraform configuration file must have its own directory (also called a root module).

  1. In Cloud Shell, create a directory and a new file within that directory. The filename must have the .tf extension—for example main.tf. In this tutorial, the file is referred to as main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. If you are following a tutorial, you can copy the sample code in each section or step.

    Copy the sample code into the newly created main.tf.

    Optionally, copy the code from GitHub. This is recommended when the Terraform snippet is part of an end-to-end solution.

  3. Review and modify the sample parameters to apply to your environment.
  4. Save your changes.
  5. Initialize Terraform. You only need to do this once per directory. 
    terraform init

    Optionally, to use the latest Google provider version, include the -upgrade option:

    terraform init -upgrade
Apply the changes
  1. Review the configuration and verify that the resources that Terraform is going to create or update match your expectations: 
    terraform plan

    Make corrections to the configuration as necessary.

  2. Apply the Terraform configuration by running the following command and entering yes at the prompt: 
    terraform apply

    Wait until Terraform displays the "Apply complete!" message.

  3. Open your Google Cloud project to view the results. In the Google Cloud console, navigate to your resources in the UI to make sure that Terraform has created or updated them.
Note: Terraform samples typically assume that the required APIs are enabled in your Google Cloud project. API

To apply access controls when the dataset is created, call the datasets.insert method with a defined dataset resource. To update your access controls, call the datasets.patch method and use the access property in the Dataset resource.

Because the datasets.update method replaces the entire dataset resource, datasets.patch is the preferred method for updating access controls.

Go

Before trying this sample, follow the Go setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Go API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Set the new access list by appending the new entry to the existing list with DatasetMetadataToUpdate type . Then call the dataset.Update() function to update the property. Java

Before trying this sample, follow the Java setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Java API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Node.js

Before trying this sample, follow the Node.js setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Node.js API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Set the new access list by appending the new entry to the existing list using the Dataset#metadata method. Then call the Dataset#setMetadata() function to update the property. Python

Before trying this sample, follow the Python setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Python API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Set the dataset.access_entries property with the access controls for a dataset. Then call the client.update_dataset() function to update the property. Predefined roles that grant access to datasets

You can grant the following IAM predefined roles access to a dataset.

Caution: While it is possible to grant BigQuery Admin or BigQuery Studio Admin permissions on a dataset, you shouldn't grant these roles at the dataset level. BigQuery Data Owner also grants all permissions for the dataset and is a less privileged role. BigQuery Admin and BigQuery Studio Admin are typically granted at the project level. Role Description BigQuery Data Owner (roles/bigquery.dataOwner) When granted on a dataset, this role grants these permissions:
Note: Principals that are granted the Data Owner role at the project level can also create new datasets and list datasets in the project that they have access to. BigQuery Data Editor (roles/bigquery.dataEditor) When granted on a dataset, this role grants these permissions:
Note: Principals that are granted the Data Editor role at the project level can also create new datasets and list datasets in the project that they have access to. BigQuery Data Viewer (roles/bigquery.dataViewer) When granted on a dataset, this role grants these permissions:
BigQuery Metadata Viewer (roles/bigquery.metadataViewer) When granted on a dataset, this role grants these permissions:
Dataset permissions

Most permissions that begin with bigquery.datasets apply at the dataset level. bigquery.datasets.create doesn't. In order to create datasets, bigquery.datasets.create permission must be granted to a role on the parent container–the project.

The following table lists all permissions for datasets and the lowest-level resource the permission can be applied to.

Permission Resource Action bigquery.datasets.create Project Create new datasets in the project. bigquery.datasets.get Dataset Get metadata and access controls for the dataset. Viewing permissions in the console also requires the bigquery.datasets.getIamPolicy permission. bigquery.datasets.getIamPolicy Dataset Required by the console to grant the user permission to get a dataset's access controls. Fails open. The console also requires the bigquery.datasets.get permission to view the dataset. bigquery.datasets.update Dataset Update metadata and access controls for the dataset. Updating access controls in the console also requires the bigquery.datasets.setIamPolicy permission. bigquery.datasets.setIamPolicy Dataset Required by the console to grant the user permission to set a dataset's access controls. Fails open. The console also requires the bigquery.datasets.update permission to update the dataset. bigquery.datasets.delete Dataset Delete a dataset. bigquery.datasets.createTagBinding Dataset Attach tags to the dataset. bigquery.datasets.deleteTagBinding Dataset Detach tags from the dataset. bigquery.datasets.listTagBindings Dataset List tags for the dataset. bigquery.datasets.listEffectiveTags Dataset List effective tags (applied and inherited) for the dataset. bigquery.datasets.link Dataset Create a linked dataset. bigquery.datasets.listSharedDatasetUsage Project List shared dataset usage statistics for datasets that you have access to in the project. This permission is required to query the INFORMATION_SCHEMA.SHARED_DATASET_USAGE view. View access controls for a dataset

You can view the explicitly set access controls for a dataset by choosing one of the following options. To view inherited roles, for a dataset, use the BigQuery web UI.

Console

  1. Go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer pane, expand your project and select a dataset.

  3. Click person_add Sharing > Permissions.

    The dataset's access controls appear in the Dataset Permissions pane.

bq

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To get an existing policy and output it to a local file in JSON, use the bq show command in Cloud Shell:

    bq show \
   --format=prettyjson \
   PROJECT_ID:DATASET > PATH_TO_FILE

    Replace the following:

SQL

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Query the INFORMATION_SCHEMA.OBJECT_PRIVILEGES view. Queries to retrieve access controls for a dataset must specify the object_name.

  1. In the Google Cloud console, go to the BigQuery page.

    Go to BigQuery

  2. In the query editor, enter the following statement:

    SELECT
COLUMN_LIST
FROM
  PROJECT_ID.`region-REGION`.INFORMATION_SCHEMA.OBJECT_PRIVILEGES
WHERE
object_name = "DATASET";

    Replace the following:

  3. Click play_circle Run.

For more information about how to run queries, see Run an interactive query.

Example:

This query gets access controls for mydataset.

SELECT
object_name, privilege_type, grantee
FROM
my_project.`region-us`.INFORMATION_SCHEMA.OBJECT_PRIVILEGES
WHERE
object_name = "mydataset";

The output should look like the following:

+------------------+-----------------------------+-------------------------+
|   object_name    |  privilege_type             | grantee                 |
+------------------+-----------------------------+-------------------------+
| mydataset        | roles/bigquery.dataOwner    | projectOwner:myproject  |
| mydataset        | roles/bigquery.dataViwer    | user:user@example.com   |
+------------------+-----------------------------+-------------------------+
API

To view the access controls for a dataset, call the datasets.get method with a defined dataset resource.

The access controls appear in the access property of the dataset resource.

Go

Before trying this sample, follow the Go setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Go API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Call the client.Dataset().Metadata() function. The access policy is available in the Access property. Java

Before trying this sample, follow the Java setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Java API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Node.js

Before trying this sample, follow the Node.js setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Node.js API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Retrieve the dataset metadata using the Dataset#getMetadata() function. The access policy is available in the access property of the resulting metadata object. Python

Before trying this sample, follow the Python setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Python API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Call the client.get_dataset() function. The access policy is available in the dataset.access_entries property. Revoke access to a dataset

To revoke access to a dataset, select one of the following options:

Console

  1. Go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer panel, expand your project and select a dataset.

  3. In the details panel, click Sharing > Permissions.

  4. In the Dataset Permissions dialog, expand the principal whose access you want to revoke.

  5. Click delete Remove principal.

  6. In the Remove role from principal? dialog, click Remove.

  7. To return to dataset details, click Close.

Note: If you cannot revoke access to the dataset, the principal may have inherited access from a higher level in the resource hierarchy. SQL

To remove a principal's access to a dataset, use the REVOKE DCL statement:

  1. In the Google Cloud console, go to the BigQuery page.

    Go to BigQuery

  2. In the query editor, enter the following statement:

    REVOKE `ROLE_LIST`
ON SCHEMA RESOURCE_NAME
FROM "USER_LIST"

    Replace the following:

  3. Click play_circle Run.

For more information about how to run queries, see Run an interactive query.

The following example revokes the BigQuery Data Owner role from myDataset:

REVOKE `roles/bigquery.dataOwner`
ON SCHEMA `myProject`.myDataset
FROM "group:group@example.com", "serviceAccount:user@test-project.iam.gserviceaccount.com"
bq

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To write the existing dataset information (including access controls) to a JSON file, use the bq show command:

    bq show \
    --format=prettyjson \
    PROJECT_ID:DATASET > PATH_TO_FILE

    Replace the following:

  3. Make changes to the access section of the JSON file. You can remove any of the specialGroup entries: projectOwners, projectWriters, projectReaders, and allAuthenticatedUsers. You can also remove any of the following: userByEmail, groupByEmail, and domain.

    For example, the access section of a dataset's JSON file would look like the following:

    {
 "access": [
  {
   "role": "READER",
   "specialGroup": "projectReaders"
  },
  {
   "role": "WRITER",
   "specialGroup": "projectWriters"
  },
  {
   "role": "OWNER",
   "specialGroup": "projectOwners"
  },
  {
   "role": "READER",
   "specialGroup": "allAuthenticatedUsers"
  },
  {
   "role": "READER",
   "domain": "domain_name"
  },
  {
   "role": "WRITER",
   "userByEmail": "user_email"
  },
  {
   "role": "READER",
   "groupByEmail": "group_email"
  }
 ],
 ...
}

  4. When your edits are complete, use the bq update command and include the JSON file using the --source flag. If the dataset is in a project other than your default project, add the project ID to the dataset name in the following format: PROJECT_ID:DATASET.

    Caution: When you apply the JSON file that contains the access controls, the existing access controls are overwritten. 
      bq update 
    
      --source PATH_TO_FILE 
    
      PROJECT_ID:DATASET

  5. To verify your access control changes, use the show command without writing the information to a file:

    bq show --format=prettyjson PROJECT_ID:DATASET
API

Call the datasets.patch method and use the access property in the Dataset resource to update your access controls.

Because the datasets.update method replaces the entire dataset resource, datasets.patch is the preferred method for updating access controls.

Go

Before trying this sample, follow the Go setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Go API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Set the new access list by removing the entry from the existing list with DatasetMetadataToUpdate type . Then call the dataset.Update() function to update the property. Java

Before trying this sample, follow the Java setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Java API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Node.js

Before trying this sample, follow the Node.js setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Node.js API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Update the dataset access list by removing the specified entry from the existing list using the Dataset#get() method to retrieve the current metadata. Modify the access property to exclude the desired entity, and then call the Dataset#setMetadata() function to apply the updated access list. Python

Before trying this sample, follow the Python setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Python API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Set the dataset.access_entries property with the access controls for a dataset. Then call the client.update_dataset() function to update the property. Work with table and view access controls

Views are treated as table resources in BigQuery. You can provide access to a table or view by granting an IAM principal a predefined or custom role that determines what the principal can do with the table or view. This is also known as attaching an allow policy to a resource. After granting access, you can view the access controls for the table or view, and you can revoke access to the table or view.

Grant access to a table or view

For fine-grained access control, you can grant a predefined or custom IAM role on a specific table or view. The table or view also inherits access controls specified at the dataset level and higher. For example, if you grant a principal the BigQuery Data Owner role on a dataset, that principal also has BigQuery Data Owner permissions on the tables and views in the dataset.

To grant access to a table or view, select one of the following options:

Console

  1. Go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer pane, expand your project and select a table or view to share.

  3. Click person_add Share.

  4. Click person_add Add principal.

  5. In the New principals field, enter a principal.

  6. In the Select a role list, select a predefined role or a custom role.

  7. Click Save.

  8. To return to the table or view details, click Close.

SQL

To grant principals access to tables or views, use the GRANT DCL statement:

  1. In the Google Cloud console, go to the BigQuery page.

    Go to BigQuery

  2. In the query editor, enter the following statement:

    GRANT `ROLE_LIST`
ON RESOURCE_TYPE RESOURCE_NAME
TO "USER_LIST"

    Replace the following:

  3. Click play_circle Run.

For more information about how to run queries, see Run an interactive query.

The following example grants the BigQuery Data Viewer role on myTable:

GRANT `roles/bigquery.dataViewer`
ON TABLE `myProject`.myDataset.myTable
TO "user:user@example.com", "user:user2@example.com"
bq

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To grant access to a table or view, use the bq add-iam-policy-binding command:

    bq add-iam-policy-binding --member=MEMBER_TYPE:MEMBER --role=ROLE
  --table=true RESOURCE

    Replace the following:

Terraform

Use the google_bigquery_table_iam resources to update access to a table.

Important: The different resources provided by google_bigquery_table_iam can conflict with each other. We recommend reading the google_bigquery_table_iam documentation carefully before making access control changes by using Terraform.

Set the access policy for a table

The following example shows how to use the google_bigquery_table_iam_policy resource to set the IAM policy for the mytable table. This replaces any existing policy already attached to the table:

# This file sets the IAM policy for the table created by
# https://github.com/terraform-google-modules/terraform-docs-samples/blob/main/bigquery/bigquery_create_table/main.tf.
# You must place it in the same local directory as that main.tf file,
# and you must have already applied that main.tf file to create
# the "default" table resource with a table_id of "mytable".

data "google_iam_policy" "iam_policy" {
  binding {
    role = "roles/bigquery.dataOwner"
    members = [
      "user:user@example.com",
    ]
  }
}

resource "google_bigquery_table_iam_policy" "table_iam_policy" {
  dataset_id  = google_bigquery_table.default.dataset_id
  table_id    = google_bigquery_table.default.table_id
  policy_data = data.google_iam_policy.iam_policy.policy_data
}

Set role membership for a table

The following example shows how to use the google_bigquery_table_iam_binding resource to set membership in a given role for the mytable table. This replaces any existing membership in that role. Other roles within the IAM policy for the table are preserved.

# This file sets membership in an IAM role for the table created by
# https://github.com/terraform-google-modules/terraform-docs-samples/blob/main/bigquery/bigquery_create_table/main.tf.
# You must place it in the same local directory as that main.tf file,
# and you must have already applied that main.tf file to create
# the "default" table resource with a table_id of "mytable".

resource "google_bigquery_table_iam_binding" "table_iam_binding" {
  dataset_id = google_bigquery_table.default.dataset_id
  table_id   = google_bigquery_table.default.table_id
  role       = "roles/bigquery.dataOwner"

  members = [
    "group:group@example.com",
  ]
}

Set role membership for a single principal

The following example shows how to use the google_bigquery_table_iam_member resource to update the IAM policy for the mytable table to grant a role to one principal. Updating this IAM policy does not affect access for any other principals that have been granted that role for the dataset.

# This file adds a member to an IAM role for the table created by
# https://github.com/terraform-google-modules/terraform-docs-samples/blob/main/bigquery/bigquery_create_table/main.tf.
# You must place it in the same local directory as that main.tf file,
# and you must have already applied that main.tf file to create
# the "default" table resource with a table_id of "mytable".

resource "google_bigquery_table_iam_member" "table_iam_member" {
  dataset_id = google_bigquery_table.default.dataset_id
  table_id   = google_bigquery_table.default.table_id
  role       = "roles/bigquery.dataEditor"
  member     = "serviceAccount:bqcx-1234567891011-12a3@gcp-sa-bigquery-condel.iam.gserviceaccount.com"
}

To apply your Terraform configuration in a Google Cloud project, complete the steps in the following sections.

Prepare Cloud Shell
  1. Launch Cloud Shell.

  2. Set the default Google Cloud project where you want to apply your Terraform configurations.

    You only need to run this command once per project, and you can run it in any directory.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Environment variables are overridden if you set explicit values in the Terraform configuration file.

Prepare the directory

Each Terraform configuration file must have its own directory (also called a root module).

  1. In Cloud Shell, create a directory and a new file within that directory. The filename must have the .tf extension—for example main.tf. In this tutorial, the file is referred to as main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. If you are following a tutorial, you can copy the sample code in each section or step.

    Copy the sample code into the newly created main.tf.

    Optionally, copy the code from GitHub. This is recommended when the Terraform snippet is part of an end-to-end solution.

  3. Review and modify the sample parameters to apply to your environment.
  4. Save your changes.
  5. Initialize Terraform. You only need to do this once per directory. 
    terraform init

    Optionally, to use the latest Google provider version, include the -upgrade option:

    terraform init -upgrade
Apply the changes
  1. Review the configuration and verify that the resources that Terraform is going to create or update match your expectations: 
    terraform plan

    Make corrections to the configuration as necessary.

  2. Apply the Terraform configuration by running the following command and entering yes at the prompt: 
    terraform apply

    Wait until Terraform displays the "Apply complete!" message.

  3. Open your Google Cloud project to view the results. In the Google Cloud console, navigate to your resources in the UI to make sure that Terraform has created or updated them.
Note: Terraform samples typically assume that the required APIs are enabled in your Google Cloud project. API

  1. To retrieve the current policy, call the tables.getIamPolicy method.

  2. Edit the policy to add members or access controls, or both. For the format required for the policy, see the Policy reference topic.

    Caution: Before you set the policy, always retrieve the current policy to obtain the current value for etag. Your updated policy file must include the same value for etag as the current policy you are replacing, or the update fails. This feature prevents concurrent updates from occurring.

    In the policy file, the value for version remains 1. This version number refers to the IAM policy schema version, not the version of the policy. The value for etag is the policy version number.

  3. Call tables.setIamPolicy to write the updated policy.

    Note: Empty bindings with no members are not allowed and result in an error.
Go

Before trying this sample, follow the Go setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Go API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Call the resource's IAM().SetPolicy() function to save changes to the access policy for a table or view. Java

Before trying this sample, follow the Java setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Java API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Node.js

Before trying this sample, follow the Node.js setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Node.js API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Call the Table#getIamPolicy() function to retrieve the current IAM policy for a table or view, modify the policy by adding new bindings, and then use Table#setIamPolicy() function to save changes to the access policy. Python

Before trying this sample, follow the Python setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Python API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Call the client.set_iam_policy() function to save changes to the access policy for a table or view. Predefined roles that grant access to tables and views

Views are treated as table resources in BigQuery. For fine-grained access control, you can grant a predefined or custom IAM role on a specific table or view. The table or view also inherits access controls specified at the dataset level and higher. For example, if you grant a principal the BigQuery Data Owner role on a dataset, that principal also has Data Owner permissions on the tables and views in the dataset.

The following predefined IAM roles have permissions on tables or views.

Caution: While it is possible to grant BigQuery Admin or BigQuery Studio Admin permissions to a table or view, you shouldn't grant these roles at the table or view level. BigQuery Data Owner also grants all permissions for tables and views and is a less permissive role. BigQuery Admin and BigQuery Studio Admin are typically granted at the project level. Role Description BigQuery Data Owner (roles/bigquery.dataOwner) When granted on a table or view, this role grants these permissions:
Note: Principals that are granted the Data Owner role at the dataset level can also create new tables and list tables in the dataset. BigQuery Data Editor (roles/bigquery.dataEditor) When granted on a table or view, this role grants these permissions:
Note: Principals that are granted the Data Editor role at the dataset level can also create new tables and list tables in the dataset. BigQuery Data Viewer (roles/bigquery.dataViewer) When granted on a table or view, this role grants these permissions:
Note: Principals that are granted the Data Viewer role at the dataset level can also list tables in the dataset. BigQuery Metadata Viewer (roles/bigquery.metadataViewer) When granted on a table or view, this role grants these permissions:
Note: Principals that are granted the Metadata Viewer role at the dataset level can also list tables in the dataset. Permissions for tables and views

Views are treated as table resources in BigQuery. All table-level permissions apply to views.

Most permissions that begin with bigquery.tables apply at the table level. bigquery.tables.create and bigquery.tables.list don't. In order to create and list tables or views, bigquery.tables.create and bigquery.tables.list permissions must be granted to a role on a parent container–the dataset or the project.

The following table lists all permissions for tables and views and the lowest-level resource they can be granted to.

Permission Resource Action bigquery.tables.create Dataset Create new tables in the dataset. bigquery.tables.createIndex Table Create a search index on the table. bigquery.tables.deleteIndex Table Delete a search index on the table. bigquery.tables.createSnapshot Table Create a snapshot of the table. Creating a snapshot requires several additional permissions at the table and dataset level. For details, see Permissions and roles for creating table snapshots. bigquery.tables.deleteSnapshot Table Delete a snapshot of the table. bigquery.tables.delete Table Delete a table. bigquery.tables.createTagBinding Table Create resource tag bindings on a table. bigquery.tables.deleteTagBinding Table Delete resource tag bindings on a table. bigquery.tables.listTagBindings Table List resource tag bindings on a table. bigquery.tables.listEffectiveTags Table List effective tags (applied and inherited) for the table. bigquery.tables.export Table Export the table's data. Running an export job also requires bigquery.jobs.create permissions. bigquery.tables.get Table Get metadata for a table. bigquery.tables.getData Table Query the table's data. Running a query job also requires bigquery.jobs.create permissions. bigquery.tables.getIamPolicy Table Get access controls for the table. bigquery.tables.list Dataset List all tables and table metadata in the dataset. bigquery.tables.replicateData Table Replicate table data. This permission is required for creating replica materialized views. bigquery.tables.restoreSnapshot Table Restore a table snapshot. bigquery.tables.setCategory Table Set policy tags in the table's schema. bigquery.tables.setColumnDataPolicy Table Set column-level access policies on a table. bigquery.tables.setIamPolicy Table Set access controls on a table. bigquery.tables.update Table Update table. metadata. bigquery.tables.get is also required to update table metadata in the console. bigquery.tables.updateData Table Update table data. bigquery.tables.updateIndex Table Update a search index on the table. View access controls for a table or view

To view the access controls for a table or view, choose one of the following options:

Console

  1. Go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer pane, expand your project, expand a dataset, and select a table or view.

  3. Click person_add Share.

    The table or view access controls appear in the Share pane.

bq

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To get an existing access policy and output it to a local file in JSON, use the bq get-iam-policy command in Cloud Shell:

    bq get-iam-policy \
    --table=true \
    PROJECT_ID:DATASET.RESOURCE > PATH_TO_FILE

    Replace the following:

SQL

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Query the INFORMATION_SCHEMA.OBJECT_PRIVILEGES view. Queries to retrieve access controls for a table or view must specify the object_schema and object_name.

  1. In the Google Cloud console, go to the BigQuery page.

    Go to BigQuery

  2. In the query editor, enter the following statement:

    SELECT
COLUMN_LIST
FROM
  PROJECT_ID.`region-REGION`.INFORMATION_SCHEMA.OBJECT_PRIVILEGES
WHERE
object_schema = "DATASET" AND object_name = "TABLE";

    Replace the following:

  3. Click play_circle Run.

For more information about how to run queries, see Run an interactive query.

Example:

SELECT
object_name, privilege_type, grantee
FROM
my_project.`region-us`.INFORMATION_SCHEMA.OBJECT_PRIVILEGES
WHERE
object_schema = "mydataset" AND object_name = "mytable";
+------------------+-----------------------------+--------------------------+
|   object_name    |  privilege_type             | grantee                  |
+------------------+-----------------------------+--------------------------+
| mytable          | roles/bigquery.dataEditor   | group:group@example.com|
| mytable          | roles/bigquery.dataOwner    | user:user@example.com|
+------------------+-----------------------------+--------------------------+
API

To retrieve the current policy, call the tables.getIamPolicy method.

Note: For views, use tables as the value for resource in this API call. Go

Before trying this sample, follow the Go setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Go API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Call the resource's IAM().Policy() function. Then call the Roles() function to get the access policy for a table or view. Java

Before trying this sample, follow the Java setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Java API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Node.js

Before trying this sample, follow the Node.js setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Node.js API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Retrieve the IAM policy for a table or view using the Table#getIamPolicy() function. The access policy details are available in the returned policy object. Revoke access to a table or view

To revoke access to a table or view, select one of the following options:

Console

  1. Go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer panel, expand your project, expand a dataset, and select a table or view.

  3. In the details panel, click Share.

  4. In the Share dialog, expand the principal whose access you want to revoke.

  5. Click delete Delete.

  6. In the Remove role from principal? dialog, click Remove.

  7. To return to the table or view details, click Close.

Note: If you can't revoke access, the principal may have inherited access from a higher level in the resource hierarchy. SQL

To remove access to tables or views from principals, use the REVOKE DCL statement:

  1. In the Google Cloud console, go to the BigQuery page.

    Go to BigQuery

  2. In the query editor, enter the following statement:

    REVOKE `ROLE_LIST`
ON RESOURCE_TYPE RESOURCE_NAME
FROM "USER_LIST"

    Replace the following:

  3. Click play_circle Run.

For more information about how to run queries, see Run an interactive query.

The following example revokes the BigQuery Data Owner role on myTable:

REVOKE `roles/bigquery.dataOwner`
ON TABLE `myProject`.myDataset.myTable
FROM "group:group@example.com", "serviceAccount:user@myproject.iam.gserviceaccount.com"
bq

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To revoke access to a table or view, use the bq remove-iam-policy-binding command:

    bq remove-iam-policy-binding --member=MEMBER_TYPE:MEMBER --role=ROLE
--table=true RESOURCE

    Replace the following:

API

  1. To retrieve the current policy, call the tables.getIamPolicy method.

  2. Edit the policy to remove members or bindings, or both. For the format required for the policy, see the Policy reference topic.

    Caution: When you set the policy, always retrieve the current policy as a first step to obtain the current value for etag. Your updated policy file must include the same value for etag as the current policy you are replacing, or the update fails. This feature prevents concurrent updates from occurring.

    In the policy file, the value for version remains 1. This version number refers to the IAM policy schema version, not the version of the policy. The value for etag is the policy version number.

  3. Call tables.setIamPolicy to write the updated policy.

Note: Empty bindings with no members are not allowed and result in an error. Go

Before trying this sample, follow the Go setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Go API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Call the policy.Remove() function to remove the access. Then call the IAM().SetPolicy() function to save changes to the access policy for a table or view. Java

Before trying this sample, follow the Java setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Java API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Node.js

Before trying this sample, follow the Node.js setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Node.js API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

Retrieve the current IAM policy for a table or view using the Table#getIamPolicy() method. Modify the policy to remove the desired role or principal, and then apply the updated policy using the Table#setIamPolicy() method. Work with access controls for routines

Preview

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

To provide feedback or request support for this feature, email bq-govsec-eng@google.com.

You can provide access to a routine by granting an IAM principal](/iam/docs/principal-identifiers#allow) a predefined or custom role that determines what the principal can do with the routine. This is also known as attaching an allow policy to a resource. After granting access, you can view the access controls for the routine, and you can revoke access to the routine.

Grant access to a routine

For fine-grained access control, you can grant a predefined or custom IAM role on a specific routine. The routine also inherits access controls specified at the dataset level and higher. For example, if you grant a principal the BigQuery Data Owner role on a dataset, that principal also has Data Owner permissions on the routines in the dataset.

Select one of the following options:

Console

  1. Go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer pane, expand your project, expand your dataset, expand Routines, and then select a routine.

  3. Click person_add Share.

  4. Click person_add Add members.

  5. In the New members field, enter a principal.

  6. In the Select a role list, select a predefined role or a custom role.

  7. Click Save.

  8. To return to the routine info, click Done.

bq

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To write the existing routine information (including access controls) to a JSON file, use the bq get-iam-policy command:

    bq get-iam-policy \
    PROJECT_ID:DATASET.ROUTINE \
    > PATH_TO_FILE

    Replace the following:

    Caution: When you set the policy, always retrieve the current policy as a first step to obtain the current value for etag. Your updated policy file must include the same value for etag as the current policy you are replacing, or the update fails. This feature prevents concurrent updates from occurring.

    In the policy file, the value for version remains 1. This version number refers to the IAM policy schema version, not the version of the policy. The value for etag is the policy version number.

  3. Make changes to the bindings section of the JSON file. A binding binds one or more principals to a single role. Principals can be user accounts, service accounts, Google groups, and domains. For example, the bindings section of a routine's JSON file would look like the following:

    {
  "bindings": [
    {
      "role": "roles/bigquery.dataViewer",
      "members": [
        "user:user@example.com",
        "group:group@example.com",
        "domain:example.com",
      ]
    },
  ],
  "etag": "BwWWja0YfJA=",
  "version": 1
}
    Note: Empty bindings with no members are not allowed and result in an error.

  4. To update the access policy, use the bq set-iam-policy command:

    bq set-iam-policy PROJECT_ID:DATASET.ROUTINE PATH_TO_FILE

  5. To verify your access control changes, use the bq get-iam-policy command again without writing the information to a file:

    bq get-iam-policy --format=prettyjson \\
    PROJECT_ID:DATASET.ROUTINE
API

  1. To retrieve the current policy, call the routines.getIamPolicy method.

  2. Edit the policy to add principals, bindings, or both. For the format required for the policy, see the Policy reference topic.

    Caution: Before you set the policy, always retrieve the current policy to obtain the current value for etag. Your updated policy file must include the same value for etag as the current policy you are replacing, or the update fails. This feature prevents concurrent updates from occurring.

    In the policy file, the value for version remains 1. This version number refers to the IAM policy schema version, not the version of the policy. The value for etag is the policy version number.

  3. Call routines.setIamPolicy to write the updated policy.

Note: Empty bindings with no members are not allowed and result in an error. Predefined roles that grant access to routines

For fine-grained access control, you can grant a predefined or custom IAM role on a specific routine. The routine also inherits access controls specified at the dataset level and higher. For example, if you grant a principal the Data Owner role on a dataset, that principal also has Data Owner permissions on the routines in the dataset through inheritance.

The following predefined IAM roles have permissions on routines.

Caution: While it is possible to grant BigQuery Admin or BigQuery Studio Admin permissions on a routine, you shouldn't grant these roles at the routine level. BigQuery Data Editor also grants all permissions for the routine and is a less permissive role. BigQuery Admin and BigQuery Studio Admin are typically granted at the project level. Role Description BigQuery Data Owner (roles/bigquery.dataOwner) When granted on a routine, this role grants these permissions:

You shouldn't grant the Data Owner role at the routine level. Data Editor also grants all permissions for the routine and is a less permissive role.

Note: Principals that are granted the Data Owner role at the dataset level can create routines and list routines in the dataset. BigQuery Data Editor (roles/bigquery.dataEditor) When granted on a routine, this role grants these permissions:
Note: Principals that are granted the Data Editor role at the dataset level can create routines and list routines in the dataset. BigQuery Data Viewer (roles/bigquery.dataViewer) When granted on a routine, this role grants these permissions:
Note: Principals that are granted the Data Viewer role at the dataset level can also list routines in the dataset. BigQuery Metadata Viewer (roles/bigquery.metadataViewer) When granted on a routine, this role grants these permissions:
Note: Principals that are granted the Metadata Viewer role at the dataset level can also list routines in the dataset. Permissions for routines

Most permissions that begin with bigquery.routines apply at the routine level. bigquery.routines.create and bigquery.routines.list don't. In order to create and list routines, bigquery.routines.create and bigquery.routines.list permissions must be granted to a role on the parent container–the dataset.

The following table lists all permissions for routines and the lowest-level resource they can be granted to.

Permission Resource Description bigquery.routines.create Dataset Create a routine in the dataset. This permission also requires bigquery.jobs.create to run a query job that contains a CREATE FUNCTION statement. bigquery.routines.delete Routine Delete a routine. bigquery.routines.get Routine Reference a routine created by someone else. This permission also requires bigquery.jobs.create to run a query job that references the routine, and you also need permission to access any resources that the routine references, such as tables or views. bigquery.routines.list Dataset List routines in the dataset and show metadata for routines. bigquery.routines.update Routine Update routine definitions and metadata. bigquery.routines.getIamPolicy Routine Get access controls for the routine. bigquery.routines.setIamPolicy Routine Set access controls for the routine. View the access controls for a routine

To view the access controls for a routine, choose one of the following options:

Console

  1. Go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer pane, expand your project, expand the dataset, expand Routines, and then select a routine.

  3. Click person_add Share.

    The routine's access controls appear in the Share pane.

bq

The bq get-iam-policy command does not provide support for viewing access controls on a routine.

SQL

The INFORMATION_SCHEMA.OBJECT_PRIVILEGES view doesn't show access controls for routines.

API

To retrieve the current policy, call the routines.getIamPolicy method.

Revoke access to a routine

To revoke access to a routine, select one of the following options:

Console

  1. Go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer panel, expand your project, expand a dataset, expand Routines, and then select a routine.

  3. In the details panel, click Sharing > Permissions.

  4. In the Routine Permissions dialog, expand the principal whose access you want to revoke.

  5. Click delete Remove principal.

  6. In the Remove role from principal? dialog, click Remove.

  7. Click Close.

Note: If you are unable to revoke access, the principal may have inherited access from a higher level in the resource hierarchy. For instructions on editing principal access, see Grant or revoke a single role. bq

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To write the existing routine information (including access controls) to a JSON file, use the bq get-iam-policy command:

    bq get-iam-policy --routine PROJECT_ID:DATASET.ROUTINE > PATH_TO_FILE

    Replace the following:

    Caution: When you set the policy, always retrieve the current policy as a first step to obtain the current value for etag. Your updated policy file must include the same etag value as the current policy that you are replacing, or the update fails. This feature prevents concurrent updates from occurring.

    In the policy file, the value for version remains 1. This number refers to the IAM policy schema version, not the version of the policy. The value for etag value is the policy version number.

  3. Make changes to the access section of the JSON file. You can remove any of the specialGroup entries: projectOwners, projectWriters, projectReaders, and allAuthenticatedUsers. You can also remove any of the following: userByEmail, groupByEmail, and domain.

    For example, the access section of a routine's JSON file would look like the following:

    {
 "bindings": [
   {
     "role": "roles/bigquery.dataViewer",
     "members": [
       "user:user@example.com",
       "group:group@example.com",
       "domain:google.com",
     ]
   },
 ],
 "etag": "BwWWja0YfJA=",
 "version": 1
}
    Note: Empty bindings with no members are not allowed and result in an error.

  4. To update the access policy, use the bq set-iam-policy command:

    bq set-iam-policy --routine PROJECT_ID:DATASET.ROUTINE PATH_TO_FILE

  5. To verify your access control changes, use the get-iam-policy command again without writing the information to a file:

    bq get-iam-policy --routine --format=prettyjson PROJECT_ID:DATASET.ROUTINE
API

  1. To retrieve the current policy, call the routines.getIamPolicy method.

  2. Edit the policy to add principals or bindings, or both. For the format required for the policy, see the Policy reference topic.

    Caution: When you set the policy, always retrieve the current policy as a first step to obtain the current value for etag. Your updated policy file must include the same value for etag as the current policy you are replacing, or the update fails. This feature prevents concurrent updates from occurring.

    In the policy file, the value for version remains 1. This version number refers to the IAM policy schema version, not the version of the policy. The value for etag is the policy version number.

View inherited access controls for a resource

You can examine the inherited IAM roles for a resource by using the BigQuery web UI. You'll need the appropriate permissions to view inheritance in the console. To examine inheritance for a dataset, table, view, or routine:

  1. In the Google Cloud console, go to the BigQuery page.

    Go to BigQuery

  2. In the Explorer pane, select the dataset, or expand the dataset and select a table, view, or routine.

  3. For a dataset, click Sharing. For a table, view, or routine, click Share.

  4. Verify that the Show inherited roles in table option is enabled.

  5. Expand a role in the table.

  6. In the Inheritance column, the hexagonal icon indicates whether the role was inherited from a parent resource.

Deny access to a resource

Preview

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Note: To provide feedback or ask questions that are related to this preview release, contact bigquery-security@google.com.

IAM deny policies let you set guardrails on access to BigQuery resources. You can define deny rules that prevent selected principals from using certain permissions, regardless of the roles they're granted.

For information about how to create, update, and delete deny policies, see Deny access to resources.

Special cases

Consider the following scenarios when you create IAM deny policies on a few BigQuery permissions:

What's next

Learn how to use the projects.testIamPermissions method to test user access to a resource.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-15 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-15 UTC."],[[["This document explains how to manage access to BigQuery resources using Identity and Access Management (IAM), covering how to view, grant, and revoke access policies."],["Modifying IAM policies for resources requires specific permissions, primarily within the `bigquery.datasets` and `bigquery.tables` categories, which can be obtained through the BigQuery Data Owner role or custom roles."],["You can view the access policy of a dataset or a table/view through the console, using the `bq` command-line tool, or by using the BigQuery API with Python code."],["Access to a dataset can be granted using the console, SQL `GRANT` statements, `bq` commands, Terraform, and API methods, allowing control over who can view or modify data."],["Revoking access involves removing principals or roles from the access policy, and can be done through the console, SQL `REVOKE` statements, `bq` commands, or API methods, with considerations for inherited access and special cases like cached results."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4