Using Cloud Bigtable with IAM Conditions and Tags

Cloud Bigtable is a low-latency, high-throughput NoSQL database. Bigtable users store terabytes of data in their tables, and exposing the data securely is essential for Bigtable users.​ If​ you are an administrator or developer responsible for securing access to your Bigtable data, ​​you are likely util​izing​ Google Cloud security features to lock down ​the Bigtable resources and customize ​your authorization model.

In this article, we are going to learn how to control access to certain Bigtable resources, create a narrow scope of your resources to apply permissions, and set permissions depending on the development environment. We'll accomplish this using Identity and Access Management (IAM), IAM Conditions, and Tags to secure Bigtable ​data.

Identity and Access Management 

IAM provides fine-grained access control and visibility for centrally managing Google Cloud resources. A complex cloud organization can have various resources that can have IAM policies bound to them, which are configured by administrators who want to control access based on roles.

The following diagram shows an administrator binding an IAM policy to a resource. An IAM policy consists of one or more principals—otherwise known as members—and an administrator can grant one or more roles to each principal. A principle can be a user, group or a service account. A role is a collection of permissions that allow a principal to perform some actions on Google Cloud resources.

Resources inherit IAM policies from their parents in the resource tree. When a user sends a request, IAM checks to see if the user has permission to perform the action on that particular resource. If the IAM policy bound to the resource can grant the permission to the user, then the permission is granted. If not, IAM goes up the resource tree to search for a policy that can grant such permission. If no policies can grant the permission are found in the resource tree, the request is rejected with a permission-denied error. 

The following Cloud Console example grants the Bigable Reader role to the user 222larabrown@gmail.com and binds the policy to the my-project project.

This can also be done through the gcloud CLI:

After the binding is created, the Bigtable Reader role is granted to 222larabrown@gmail.com within the my-project project. This means that 222larabrown@gmail.com can have read access to data in existing tables and to metadata for instances, clusters, and tables, including column families.

There are three types of roles in IAM: basic, predefined, and custom. The Bigtable Reader role is a predefined role. See Understanding roles to learn more about IAM roles.

IAM Conditions

IAM Conditions is a feature that allows the defining and enforcing of conditional, attribute-based access control for Google Cloud resources. In addition to the role binding to a resource, the resource access is granted to a principal only if the configured condition is met.

The following illustrates how IAM Conditions works.

The following Cloud Console example grants the Bigable Reader role to the user 222larabrown@gmail.com with the "Report tables" condition and binds the policy to the my-project project. With the Report tables condition, 222larabrown@gmail.com has read access to Bigtable tables that contain a prefix of report- in the table ID within the specific Bigtable instance.

The condition Report tables is defined so that:

• The source type has to be the Bigtable table bigtableadmin.googleapis.com/Table.

• The resource (table) name has to have the prefix of projects/my-project/instances/my-instance/tables/report-.

• The service has to be the Bigtable Admin service: bigtableadmin.googleapis.com.

This can also be done through the gcloud CLI:

The CONDITION_FROM_FILE should be a path to a local JSON or YAML file that defines the following condition:

IAM Conditions with Tags

What if 222larabrown@gmail.com should only be allowed to have read access to the data in the Test or Staging environment because Prod has sensitive data that should not be exposed to 222larabrown@gmail.com? One way to achieve this is by binding some environment tag values to the right resources and limiting access to the resource with associated tag values using IAM Conditions.

Tags are a good way to manage the resources in your organization hierarchy by adding additional business dimensions. You can use tags to group certain resources for different purposes such as access control. We are going to explore using tags to group resources for different environments, such as Test, Staging, and Prod.

First, in the Cloud Console, you can create a tag at the organization level to represent the environments. The new tag has values of Test, Staging and Prod.

Once the tag is created, it generates one tag key ID for the tag and three tag value IDs for the three tag values.

Let's say you want to use a Bigtable instance, my-instance, for your Test environment. You can bind the Test tag value in the Environment tag to the instance as follows, using the gcloud CLI.

Note: Currently there is no Cloud Console support for binding tags to Bigtable instances.

Once the binding is in effect, you can add a condition and only grant the role to the principal if the resource has a tag value that matches the Test tag value. Now the user 222larabrown@gmail.com has access only to the Test environment.

Note: Combining tags and other attributes in the same condition is currently not allowed.

See Tags and access control  for more information.

Summary

In this article you learned:

• IAM fundamentals

• How to set IAM roles for Bigtable resources 

• How to limit the scope of an IAM role further with IAM Conditions

• How to add an environment requirement for permissions using IAM Tags

Learn More

To learn more about using IAM, IAM Conditions to secure your Bigtable data, see Access control with IAM.