Code360 powered by Coding Ninjas X Naukri.com. Code360 powered by Coding Ninjas X Naukri.com
Last Updated: Mar 27, 2024

Security and Authentication in Cloud Big Table

Leveraging ChatGPT - GenAI as a Microsoft Data Expert
Speaker
Prerita Agarwal
Data Specialist @
23 Jul, 2024 @ 01:30 PM

Introduction

Hello readers, we hope you are doing great.

In this article, we will discuss the Security and Authentication in Cloud BigTable. We will discuss the different types of authentication methods supported by Cloud BigTable and also look at an important encryption technique.

Authentication

The following authentication methods are supported by Bigtable.

Service accounts

Whether developing locally or in a production application, service accounts are suggested for practically all use scenarios. See Bigtable client libraries for an example of how to set up authentication with a service account.

User accounts

For almost all use scenarios, using a service account rather than a user account is recommended.

When your application wants to access resources on an end user's behalf, you can authenticate users directly to your application. When creating a method cache, you must specify OAuth scopes if your application employs end-user authentication.

Get the tech career you deserve, faster!
Connect with our expert counsellors to understand how to hack your way to success
User rating 4.7/5
1:1 doubt support
95% placement record
Akash Pal
Senior Software Engineer
326% Hike After Job Bootcamp
Himanshu Gusain
Programmer Analyst
32 LPA After Job Bootcamp
After Job
Bootcamp

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.

Admin Activity audit logs

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.

Data Access audit logs

System Event audit logs

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

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 BigTableWe hope that this blog has helped you enhance your knowledge, to learn more, check out the awesome content on the Coding Ninjas Website:
Android DevelopmentCoding Ninjas Studio ProblemsCoding Ninjas Studio Interview BundleCoding Ninjas Studio Interview ExperiencesCoding Ninjas CoursesCoding Ninjas Studio Contests, and Coding Ninjas Studio Test SeriesDo upvote our blog to help other ninjas grow. Happy Coding!

Thank you image

Topics covered
1.
Introduction
2.
Authentication
2.1.
Service accounts
2.2.
User accounts
3.
Access control with IAM
4.
Audit logging
4.1.
Available audit logs
4.2.
Admin Activity audit logs
4.2.1.
Data Access audit logs
4.2.2.
System Event audit logs
4.3.
Audit log format
5.
Customer-managed encryption keys (CMEK)
5.1.
Features
6.
Frequently Asked Questions
6.1.
How are we charged for CMEK pricing?
6.2.
Is data in transit or in memory protected by the CMEK key?
6.3.
When a Bigtable cluster is disabled, which admin operations are restricted for the entire instance?
7.
Conclusion