Google CloudOverview
Customer-Supplied Encryption Keys (CSEK) are a feature in Google Cloud Storage and Google Compute Engine. If you supply your own encryption keys, Google uses your key to protect the Google-generated keys used to encrypt and decrypt your data. By default, Google Compute Engine encrypts all data at rest. Compute Engine handles and manages this encryption for you without any additional actions on your part. However, if you wanted to control and manage this encryption yourself, you can provide your own encryption keys.
Rationale
By default, Google Compute Engine encrypts all data at rest. Compute Engine handles and manages this encryption for you without any additional actions on your part. However, if you wanted to control and manage this encryption yourself, you can provide your own encryption keys.
If you provide your own encryption keys, Compute Engine uses your key to protect the Google-generated keys used to encrypt and decrypt your data. Only users who can provide the correct key can use resources protected by a customer-supplied encryption key.
Google does not store your keys on its servers and cannot access your protected data unless you provide the key. This also means that if you forget or lose your key, there is no way for Google to recover the key or to recover any data encrypted with the lost key.
At least business critical VMs should have VM disks encrypted with CSEK.
Remediation guidance
Existing disks cannot be converted in place from Google-managed encryption to CSEK. If this control is mandatory in your environment, create replacement disks or instances with customer-supplied keys from the start.
Using Google Cloud Console
- Open
Compute Engine->Disks. - Create a new disk or recreate the workload from a new disk.
- Under
Encryption, chooseCustomer-supplied key. - Enter the raw or wrapped key material required for the disk.
- Reattach or rebuild the workload on the newly created encrypted disk.
Using Google Cloud CLI
Create a key file that contains the URI of the target resource and the encryption key. Then create the disk or VM with --csek-key-file.
Example new disk with a raw key:
gcloud compute disks create <disk-name> --zone=<zone> --size=<size-gb> --type=<disk-type> --csek-key-file=<example-file.json>
Example VM boot disk with a raw key:
gcloud compute instances create <instance-name> --zone=<zone> --image-family=<image-family> --image-project=<image-project> --csek-key-file=<example-file.json>
If you use RSA-wrapped keys, Google still documents gcloud beta for those specific CSEK flows.
Validation
Describe the disk and confirm the customer-supplied key SHA-256 fingerprint is present:
gcloud compute disks describe <disk-name> --zone=<zone> --format='yaml(diskEncryptionKey)'
Best-practice note
CSEK gives you maximum custody of key material, but it also carries the most operational burden. If your objective is strong customer-controlled encryption with easier rotation and recovery handling, CMEK is often the more supportable platform standard. Keep this control only if your policy explicitly requires CSEK.
References
- https://cloud.google.com/compute/docs/disks/customer-supplied-encryption
- https://cloud.google.com/compute/docs/reference/rest/v1/disks/get
Service-wide remediation
Recommended when many resources are affected: decide at the platform level whether you truly require CSEK or whether CMEK satisfies the policy intent with lower operational risk.
If CSEK is required, bake the key-file workflow, secure key handling, and recovery testing into your VM provisioning pipeline.
Operational rollout
- Confirm that the business requirement really calls for CSEK rather than CMEK.
- Rebuild or replace critical workloads on new CSEK-backed disks.
- Verify key custody procedures before decommissioning the old disks.
Query logic
These are the stored checks tied to this control.
VM disks for critical VMs are encrypted with Customer-Supplied Encryption Keys (CSEK)
Connectors
Covered asset types
Expected check: eq []
disks(where:{encryptedWithCustomerSuppliedKey: false }){...AssetFragment}
