Cloud KMS & CMEK

Envelope encryption, key IAM, rotation, kill switch.

All GCP data at rest is encrypted by default with Google-managed keys — the security question is not "is it encrypted?" but "who controls the key?". Customer-managed encryption keys (CMEK) in Cloud KMS are how you take that control, and understanding envelope encryption is what makes rotation and revocation make sense.

CMEK and envelope encryption

With CMEK you create a key in Cloud KMS and point a service (a bucket, a BigQuery dataset, a disk) at it. Under the hood it is envelope encryption: a data encryption key encrypts the data and is itself wrapped by your key-encryption key in KMS, so bulk data never transits KMS and a single key protects any volume. The payoff is control — you own the rotation schedule, the IAM on the key, and the ability to disable it, which instantly makes the data unreadable.

# A key ring + key with 90-day automatic rotation.
gcloud kms keyrings create app --location=europe-west1
gcloud kms keys create data --location=europe-west1 --keyring=app \
  --purpose=encryption --rotation-period=90d --next-rotation-time=+p90d
 
# Point a bucket at it (the bucket's service agent needs encrypterDecrypter).
gcloud storage buckets update gs://payments-data \
  --default-encryption-key=projects/PROJ/locations/europe-west1/keyRings/app/cryptoKeys/data

The key IAM is the real control

Reading the ciphertext store is not enough — the caller also needs roles/cloudkms.cryptoKeyEncrypterDecrypter on the key. That decoupling is the point: a bucket reader without key access sees only ciphertext. Separate the key admin (roles/cloudkms.admin) from key users so no single compromised role can both manage and use the key, rotate on a schedule (old versions still decrypt existing data, so no re-encryption), and remember that disabling a key version is an instant, global revocation you can wield during an incident.