Bigtable access control with IAM

This page describes the access control options in Bigtable.

Overview

Bigtable usesIdentity and Access Management (IAM) foraccess control. You set IAM policies on resources to control who has what access to which resources.

Bigtable resources are organized in a hierarchy. AGoogle Cloud project is the parent of a Bigtableinstance, which is the parent of its clusters and tables. A table is the parentof its authorized views while a cluster is the parent of its backups. Youcan configure access control at each level.

If you have permissions at a level, then you automatically have permissionsbelow that level. For example, if you have access at the project level, then youhave access to the instances, clusters, tables, authorized views,continuous materialized views in that project. If you are granted access toan authorized view or a continuous materialized view, then youdon't automatically have access to higher-level resources that are parents ofthe authorized view or continuous materialized view, such as thetable and instance. This behavior is calledpolicy inheritance.

For more information about IAM hierarchy, seeIAM policyinheritance.

Here are some examples of using access control at theproject level:

• Allow a user to read from, but not write to, any table within the project.
• Allow a user to read from and write to any table within the project, but notmanage instances.
• Allow a user to read from and write to any table within the project, andmanage instances.

Examples of using access control at theinstance level include thefollowing:

• Allow a user to read from any table in only one instance in a project thathas multiple instances.
• Allow a user to manage only one instance in a project that has multipleinstances.

Examples of using access control at thetable level include the following:

• Allow a user to write to a table but not read from the table.
• Allow a user to read from a table but not write to the table.

Examples of using access control at thebackup level include the following:

• Prevent a user from deleting a backup.
• Prevent a user from restoring from the backup.

Examples of using access control at theauthorized view levelinclude the following:

• Let a user read an authorized view but not modify it.
• Let a user view data from only one of multiple authorized views of atable.

Examples of using access control at thecontinuous materialized viewlevel include the following:

• Let a user read from a continuous materialized view but not modifythe underlying table.

For a detailed description of IAM and its features, see theIAMdeveloper's guide. In particular, seeGranting, Changing, and RevokingAccess.

In Bigtable, you cannot grant access to the followingtypes ofprincipals:

• allAuthenticatedUsers
• allUsers

For lists of the permissions and roles that Bigtable supports, seethe following sections.

Enabling the Bigtable API

To view and assign Bigtable IAM roles, you must enable theBigtable API for your project. You won't be able to see theBigtable roles in the Google Cloud console until you enable theAPI.

Enable the API

Permissions

This section summarizes the permissions that Bigtable supports.

Permissions allow users to perform specific actions on Bigtableresources. For example, thebigtable.instances.list permissions allows usersto list all of the Bigtable instances within a project. You don'tgrant permissions to users directly; instead, you assign each user apredefinedrole orcustom role, which grants one or morepermissions.

The following tables list the IAM permissions that are associated withBigtable:

Predefined roles

Each predefined role is a bundle of one or morepermissions. Forexample,roles/bigtable.reader provides read-only access to information aboutBigtable instances, clusters, tables, and column families, as wellas the data contained within your tables. You assign roles to users or groups,which allows them to perform actions on the resources in your project.

The following table lists the predefined roles for Bigtable,including a list of the permissions associated with each role:

Custom roles

If thepredefined roles for Bigtable don't address yourbusiness requirements, you can define your owncustom roleswith permissions that you specify.

If your custom role needs to support access to the Google Cloud console, youmust identify the tasks that users will perform, then ensure that the customrole has the required permissions for each task, as shown in the followingtable. If a custom role does not have all of the required permissions for atask, and a user tries to perform that task, the Google Cloud console won'twork correctly.

IAM management

This section explains how to manage IAM roles and related permissions atproject, instance, table, and backup level.

Project-level IAM management

At the project level, you can grant, change, and revoke IAM roles using theGoogle Cloud console, the IAM API, or the Google Cloud CLI. SeeGranting,Changing, and Revoking Access for detailed instructions.

Once you create a project, you can grant the project level IAM roles to usersbased on the specific access levels.

Required roles

Before you setinstance-level,table-level,backup-level,authorized view-level, or continuous materialized view-level IAMroles for a user, ensure that the user has at least one of the followingproject-level IAM roles:

• Bigtable Viewer (recommended)
• Bigtable Reader
• Bigtable User
• Bigtable Administrator

At the instance level, you can grant any of Bigtable'spredefinedroles to a user or service account. You can also grant anycustomroles that you have defined.

+<var>INSTANCE_ID</var>:Thepermanentidentifierfortheinstance.+<var>POLICY_FILE</var>:PathtoalocalJSONorYAMLfilecontaininga[validIAMpolicy][iam-policy].

Granting table-level IAM roles

At the table level, you can grant any of Bigtable'spredefinedroles to a user or service account. You can also grant anycustomroles that you have defined.

+<var>INSTANCE_ID</var>:Thepermanentidentifierfortheinstance.

+<var>TABLE_ID</var>:Thepermanentidentifierforthetable.+<var>INSTANCE_ID</var>:Thepermanentidentifierfortheinstance.+<var>POLICY_FILE</var>:PathtoalocalJSONorYAMLfilecontaininga[validIAMpolicy][iam-policy].

Granting backup-level IAM roles

At the backup level, you can grant any of Bigtable'spredefinedroles to a user or service account. You can also grant anycustomroles that you have defined.

+<var>INSTANCE_ID</var>:Thepermanentidentifierfortheinstance.

+<var>BACKUP_ID</var>:Thepermanentidentifierforthebackup.+<var>INSTANCE_ID</var>:Thepermanentidentifierfortheinstance.+`TABLE_ID`:Thepermanentidentifierforthetable+`POLICY_FILE`:PathtoalocalJSONorYAMLfilecontaininga[validIAMpolicy][iam-policy].

Granting authorized view-level IAM roles

At the authorized view level, you can grant any ofBigtable'spredefined roles to a user or service account.You can also grant anycustom roles that you have defined.

+`INSTANCE_ID`:Thepermanentidentifierfortheinstance.+`TABLE_ID`:Thepermanentidentifierforthetable+`AUTHORIZED_VIEW_ID`:Thepermanentidentifierfortheview+`POLICY_FILE`:PathtoalocalJSONorYAMLfilecontaininga[validIAMpolicy][iam-policy].

IAM conditions

IAM Conditions let you define and enforceconditional, attribute-based access control for some Google Cloudresources, including Bigtable resources.

In Bigtable, you can enforce conditional access based on thefollowing attributes:

• Date/time attributes: Use to set temporary (expiring),scheduled, or limited-duration access to Bigtable resources.For example, you can allow a user to access a table until a specified date.
• Resource attributes: Use to configure conditionalaccess based on a resource name, resource type, or resource serviceattributes. In Bigtable, you can use attributes of instances,clusters, tables, backups, and authorized views to configureconditional access. For example, you can allow a user to manage tables onlyon tables that begin with a specific prefix, or you can allow a user toaccess only a specific table.

For more information about IAM Conditions, see theConditionsoverview.

What's next

Learn more aboutIAM.