Cloud KMS and Customer-Managed Keys

Cloud Key Management Service (Cloud KMS) is a Google Cloud service for managing cryptographic keys for your cloud services. It allows you to create, import, rotate, and destroy keys, and use them to encrypt/decrypt data at rest across Google Cloud products like Cloud Storage, BigQuery, Compute Engine (persistent disks), and Cloud SQL. The primary reason Cloud KMS exists is to give customers control over their encryption keys, enabling compliance with regulations (e.g., HIPAA, PCI-DSS, FedRAMP) that require the customer to manage keys, not the cloud provider.

Google Cloud offers three tiers of key management: - Google-managed encryption keys: Default. Google creates and manages keys. No customer control. - Customer-managed encryption keys (CMEK): You create and manage keys in Cloud KMS. Google uses your key to encrypt data, but you control lifecycle and access. - Customer-supplied encryption keys (CSEK): You bring your own key material (e.g., from an on-premises HSM) and pass it with each API call. Google never stores your key. Only supported for Cloud Storage and Compute Engine.

The ACE exam focuses heavily on CMEK because it is the most common enterprise configuration.

When you enable CMEK on a Google Cloud resource (e.g., a Cloud Storage bucket), the following happens:

This envelope encryption ensures that your KEK never leaves Cloud KMS, and the service never has access to the KEK in plaintext.

- Key rings: Regional or multi-regional (e.g., global, us-central1). Key rings cannot be moved or renamed after creation. - Key types: - Symmetric: AES-256 (default). Used for most Google Cloud services. - Asymmetric: RSA 2048/3072/4096 or EC P-256/P-384. Used for signing or encrypting outside of Google Cloud. - Key rotation: Automatic rotation period can be set from 1 day to 100 years (default is 90 days). Manual rotation is immediate. - Key states: Enabled, Disabled, Scheduled for destruction (with a 24-hour cancellation window), Destroyed. - Key versions: Each rotation creates a new version. Old versions are retained until destroyed. The primary version is used for encryption; decryption uses the version that encrypted the data. - Import: You can import your own key material using gcloud kms import-job and then gcloud kms keys versions import. The key material must be wrapped using a Google-provided import method. - Audit logging: All KMS API calls are logged to Cloud Audit Logs. You can monitor for unauthorized access attempts.

Creating a key ring and key:

gcloud kms keyrings create my-keyring --location global
gcloud kms keys create my-key --location global --keyring my-keyring --purpose encryption --rotation-period 90d --next-rotation-time 2025-01-01T00:00:00Z

Granting IAM to a service account:

gcloud kms keys add-iam-policy-binding my-key --location global --keyring my-keyring --member serviceAccount:service-<PROJECT_NUMBER>@gs-project-accounts.iam.gserviceaccount.com --role roles/cloudkms.cryptoKeyEncrypterDecrypter

Verifying key state:

gcloud kms keys list --location global --keyring my-keyring
gcloud kms keys describe my-key --location global --keyring my-keyring

Enabling CMEK on a Cloud Storage bucket:

gsutil mb -p my-project -c STANDARD -l US-EAST1 -b on gs://my-bucket
gsutil kms authorize -k projects/my-project/locations/global/keyRings/my-keyring/cryptoKeys/my-key
gsutil kms encryption -k projects/my-project/locations/global/keyRings/my-keyring/cryptoKeys/my-key gs://my-bucket

A hospital migrating patient records to Cloud Storage must ensure that encryption keys are managed by their own security team. They use CMEK with a key ring in us-central1 to meet data residency requirements. The key is rotated every 30 days (shorter than the default 90). The hospital grants the Cloud Storage service account the Encrypter/Decrypter role. They also set up Cloud Audit Logs to monitor any decryption requests outside business hours. A common pitfall: they initially created the key ring in the wrong region and had to delete and recreate it, causing a delay. Performance is negligible because envelope encryption adds minimal overhead (sub-millisecond KMS API calls). If the key is accidentally disabled, all access to the bucket fails until re-enabled.

A SaaS company uses BigQuery with CMEK to isolate customer data. Each customer gets a separate key in a key ring. The key is used to encrypt a BigQuery dataset. IAM conditions restrict decryption to only the customer's service account. This ensures that even Google engineers cannot access the data. The company uses automatic rotation (90 days) to comply with PCI-DSS. A common issue: when a customer leaves, they must schedule key destruction. They set a 30-day delay (the maximum allowed is 30 days? Actually, the delay is 24 hours for destruction, but they can use a retention policy on the key ring). They learned that destroying a key immediately makes data inaccessible, so they first copy the data to a new dataset with a new key.

A bank uses Cloud EKM to integrate with their on-premises HSM. They create an external key in Cloud KMS that points to their HSM. The bank retains full control over the key material. This satisfies regulations that require keys to never leave the bank's premises. However, they must ensure network connectivity between Google Cloud and their HSM. If the connection drops, all crypto operations fail. They have a redundant HSM setup to avoid downtime. The ACE exam may test that EKM is a separate product from CMEK and requires additional setup.