Bigtable Cluster Should Be Encrypted With Customer Managed

More Info:

Ensure that Bigtable clusters are encrypted with CMKs

Risk Level

High

Address

Security

Compliance Standards

GDPR
HIPAA
HITRUST CSF
ISO 27001
NIST
SOC2
Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework

Triage and Remediation

Remediation

Remediation

Using Console

To remediate the misconfiguration "Bigtable Cluster Should Be Encrypted With Customer Managed Keys" for GCP using GCP Console, please follow the below steps:

Log in to your GCP Console.
Go to the Bigtable instances page by clicking on "Navigation Menu > Bigtable" or by searching for "Bigtable" in the search bar.
Select the Bigtable instance that you want to remediate.
Click on the "Encryption" tab.
Under the "Encryption at rest" section, select "Customer-managed key".
Click on "Create a key".
Choose the location for the key.
Choose the key ring for the key.
Enter a name for the key.
Click on "Create".
Select the newly created key from the dropdown menu.
Click on "Save" to save the changes.

After following these steps, your Bigtable cluster will be encrypted with customer-managed keys and the misconfiguration will be remediated.

Using CLI

To remediate the misconfiguration in GCP, follow these steps:

Open the Google Cloud Console and select the project where the Bigtable cluster is located.
Open the Cloud Shell by clicking on the icon in the top right corner of the console.
In the Cloud Shell, run the following command to enable the Cloud Key Management Service (KMS) API:
```
gcloud services enable cloudkms.googleapis.com
```
Create a new keyring in the Cloud KMS:
```
gcloud kms keyrings create <keyring-name> --location <location>
```
Replace <keyring-name> with a name for the keyring and <location> with the location where the keyring will be stored (for example, us-central1).

Create a new key in the keyring:

gcloud kms keys create <key-name> --keyring <keyring-name> --location <location> --purpose encryption

Replace <key-name> with a name for the key.

Get the resource ID of the key:

gcloud kms keys describe <key-name> --keyring <keyring-name> --location <location> --format="value(name)"

Update the Bigtable cluster to use the customer-managed encryption key:
```
gcloud beta bigtable clusters update <cluster-id> --location <location> --encryption-type=customer-managed --kms-key-name=<key-resource-id>
```
Replace <cluster-id> with the ID of the Bigtable cluster and <key-resource-id> with the resource ID of the key obtained in step 6.
Verify that the Bigtable cluster is now using the customer-managed encryption key:
```
gcloud beta bigtable clusters describe <cluster-id> --location <location> --format="value(encryptionConfig.kmsKeyName)"
```
This command should return the resource ID of the key.

That's it! Your Bigtable cluster is now encrypted with a customer-managed key.

Using Python

To remediate the misconfiguration "Bigtable Cluster Should Be Encrypted With Customer Managed Keys" for GCP using Python, you can follow the below steps:

Enable the Cloud Key Management Service (KMS) API for your project.
Create a new key ring and a new key in the Cloud KMS.
Grant the necessary permissions to the Cloud KMS key.
Create a new instance of the Bigtable client library.
Retrieve the Bigtable cluster instance by its ID.
Create a new instance of the google.cloud.bigtable_admin_v2.types.EncryptionInfo class.
Set the encryption_type property of the EncryptionInfo instance to google.cloud.bigtable_admin_v2.enums.EncryptionInfo.EncryptionType.CUSTOMER_MANAGED_ENCRYPTION.
Set the kms_key_name property of the EncryptionInfo instance to the name of the Cloud KMS key.
Update the Bigtable cluster instance with the new encryption configuration by calling the update_cluster method of the Bigtable client library.

Here's a sample Python code to remediate the misconfiguration "Bigtable Cluster Should Be Encrypted With Customer Managed Keys":

from google.cloud import bigtable_admin_v2
from google.cloud.bigtable_admin_v2.types import EncryptionInfo, EncryptionType

# Set the project ID and the Bigtable instance ID
project_id = 'your-project-id'
instance_id = 'your-instance-id'

# Set the Cloud KMS key name
kms_key_name = 'projects/{}/locations/{}/keyRings/{}/cryptoKeys/{}'.format(
    project_id, 'global', 'your-key-ring', 'your-key')

# Create a new instance of the Bigtable client library
client = bigtable_admin_v2.BigtableInstanceAdminClient()

# Retrieve the Bigtable cluster instance by its ID
cluster_name = client.cluster_path(project_id, instance_id, 'your-cluster-id')
cluster = client.get_cluster(cluster_name)

# Create a new instance of the EncryptionInfo class
encryption_info = EncryptionInfo()

# Set the encryption type to CUSTOMER_MANAGED_ENCRYPTION
encryption_info.encryption_type = EncryptionType.CUSTOMER_MANAGED_ENCRYPTION

# Set the Cloud KMS key name
encryption_info.kms_key_name = kms_key_name

# Update the Bigtable cluster instance with the new encryption configuration
update_mask = {'paths': ['encryption_config']}
update_cluster_request = {
    'cluster': cluster,
    'update_mask': update_mask,
    'encryption_config': encryption_info
}
client.update_cluster(update_cluster_request)

Note: Make sure to replace the placeholders your-project-id, your-instance-id, your-cluster-id, your-key-ring, and your-key with the actual values specific to your GCP project and Bigtable instance.

Using Terraform

# Customer-managed key for Bigtable
resource "google_kms_key_ring" "bigtable_kr" {
  project  = "YOUR_PROJECT_ID"          # replace with your project ID
  name     = "YOUR_KEY_RING_NAME"       # replace with desired key ring name
  location = "YOUR_KMS_LOCATION"        # e.g. "us-central1"
}

resource "google_kms_crypto_key" "bigtable_key" {
  name            = "YOUR_CMEK_NAME"    # replace with desired key name
  key_ring        = google_kms_key_ring.bigtable_kr.id
  rotation_period = "2592000s"          # 30 days; adjust as needed
}

# Allow Bigtable to use the CMEK
data "google_project" "current" {}

resource "google_kms_crypto_key_iam_member" "bigtable_use_key" {
  crypto_key_id = google_kms_crypto_key.bigtable_key.id
  role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
  member        = "serviceAccount:service-${data.google_project.current.number}@gcp-sa-bigtable.iam.gserviceaccount.com"
}

# Bigtable instance and CMEK-encrypted cluster
resource "google_bigtable_instance" "this" {
  name          = "YOUR_BIGTABLE_INSTANCE_ID"  # replace with instance ID
  project       = "YOUR_PROJECT_ID"            # replace with your project ID
  display_name  = "YOUR_INSTANCE_DISPLAY_NAME" # replace as needed
  instance_type = "PRODUCTION"                 # or DEVELOPMENT

  cluster {
    cluster_id   = "YOUR_CLUSTER_ID"           # replace with cluster ID
    zone         = "YOUR_BIGTABLE_ZONE"        # e.g. "us-central1-b"
    num_nodes    = 3                           # adjust as needed
    storage_type = "SSD"

    # This is the key setting that fixes the finding:
    kms_key_name = google_kms_crypto_key.bigtable_key.id
  }

  # add other configuration as needed (additional clusters, etc.)
}

Using kms_key_name on the Bigtable cluster enforces customer-managed encryption as required.
Changing or adding CMEK to an existing Bigtable cluster forces recreation of that cluster (and typically the instance) – plan for downtime and data migration; this is irreversible for the existing encrypted data.

Verification: terraform plan should show the Bigtable cluster being created (or replaced) with kms_key_name = "projects/YOUR_PROJECT_ID/locations/…/keyRings/…/cryptoKeys/…", and the KMS resources and IAM binding being added with no further changes.

Additional Reading:

https://cloud.google.com/bigtable/docs/cmek

More Info:​

Risk Level​

Address​

Compliance Standards​

Triage and Remediation​

Remediation​

Additional Reading:​