Security and Authentication in Cloud Big Table

Access control with IAM

For access control, Bigtable employs Identity and Access Management (IAM). Access control for Bigtable can be configured at the project, instance, and table levels. Here are some instances of project-level access control:

• Allow a user to read from any table in the project but not write to it.
• Allow users to view and write to any table in the project but not manage instances.
• Allow users to access and write to any table in the project, as well as manage instances.

Here are some examples of employing access control at the instance level:

• Allow a user to read from any table in only one instance of a multi-instance project.
• Allow a user to control only one instance in a multi-instance project.

The following are some examples of employing access control at the table level:

• Allow users to write to but not read from tables.
• Allow users to read to but not write from tables.

You cannot grant access to the following sorts of principals in Bigtable:

• allAuthenticatedUsers: It is a unique identifier for all service accounts and internet users that have authenticated with a Google Account. Accounts that aren't linked to a Google Workspace account or a Cloud Identity domain, such as personal Gmail accounts, are included in this identifier. Non-authenticated users, such as anonymous visitors, are excluded.
• allUsers: It is a unique identity that represents all internet users, whether authenticated or unauthenticated.

Audit logging

Audit logs help in tracking user activity, and security teams can investigate breaches and ensure compliance with regulatory requirements.

Available audit logs

Bigtable supports the following types of audit logs:

Admin Activity audit logs

"Admin write" activities that write metadata or configuration information are included. Admin Activity audit logs cannot be disabled.

Data Access audit logs

It includes "Admin read" activities that read metadata or configuration information. Data read and write actions that read or write user-supplied data are also included. You must explicitly allow Data Access audit logs to receive them.

System Event audit logs

Identifies automated Google Cloud actions that modify the configuration of resources. You can't disable System Event audit logs.

Audit log format

The following objects are included in audit log entries:

• The log entry itself is a LogEntry object. The following are examples of useful fields:
  • LogName: It contains the resource ID and audit log type.
  • Resource: It contains the target of the audited operation.
  • Timestamp: It contains the time of the audited operation.
  • ProtoPayload: It contains the audited information.
• The audit logging data is an AuditLog object stored in the log entry's protoPayload field.
• Service-specific audit information, which is a service-specific object, is optional. Earlier integrations store this item in the AuditLog object's service data field; subsequent integrations store it in the metadata field.

Customer-managed encryption keys (CMEK)

All data at rest in Cloud Bigtable is encrypted by default using Google's default encryption. Bigtable handles and administers the encryption for you, requiring no more action from you.

If you have unique compliance or legal requirements for the keys that safeguard your data, you can utilise Bigtable with customer-managed encryption keys (CMEK). Instead of Google controlling the encryption keys that safeguard your data, your Bigtable instance is safeguarded by a key that you control and manage in Cloud Key Management Service (Cloud KMS).

Features

• Flexibility: Depending on your business needs, you can use the same CMEK key in several projects, instances, or clusters, or you can utilise distinct keys.
• Data access control: Administrators can rotate, limit access to, and disable or destroy the key used in Bigtable to protect data at rest.
• Security: CMEK offers the same level of security as Google's default encryption but with greater administrative control.
• Comparable performance: Bigtable CMEK-protected instances outperform Bigtable instances that employ Google's default encryption.
• Auditability: All CMEK key activities are logged and visible in Cloud Logging. Key Access Justification is supported by Cloud EKM keys, which adds a justification field to all key requests. You can automatically approve or refuse these requests with select external key management partners based on the justification.
• Cross-region protection: CMEK can be enabled in instances with clusters in any location where Bigtable is available. A CMEK key in the region of each cluster protects it.

Frequently Asked Questions

How are we charged for CMEK pricing?

Cloud KMS assesses fees for the cost of the key as well as any cryptographic operations performed with that key.

Is data in transit or in memory protected by the CMEK key?

No, this kind of data is protected by the Google default encryption at rest and not the CMEK key.

When a Bigtable cluster is disabled, which admin operations are restricted for the entire instance?

The creation and deletion of a cluster and a table are restricted. Modifying a column family is also restricted.

Conclusion 

In this article, we have extensively discussed the Security and Authentication in Cloud BigTable. We hope that this blog has helped you enhance your knowledge, to learn more, check out the awesome content on the Coding Ninjas Website:
Android Development, Coding Ninjas Studio Problems, Coding Ninjas Studio Interview Bundle, Coding Ninjas Studio Interview Experiences, Coding Ninjas Courses, Coding Ninjas Studio Contests, and Coding Ninjas Studio Test Series. Do upvote our blog to help other ninjas grow. Happy Coding!