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
Currently there is no way to update the encryption of an existing disk. Therefore create a new disk with Encryption set to Customer supplied
Using Console
- Go to
Compute Engine - Go to
Disks - For each disk
- Set
EncryptiontoCustomer supplied - Provide the
Keyin the box - Select
Wrapped key - Click
Create
**Via CLI **
In the gcloud compute tool, encrypt a disk using the --csek-key-file flag during instance creation. If you are using an RSA-wrapped key, use the gcloud beta component:
gcloud (beta) compute instances create <instanceName> --csek-key-file `<example-file.json>`
To encrypt a standalone persistent disk:
gcloud (beta) compute disks create <diskName> --csek-key-file `<example- file.json>`
References
- https://cloud.google.com/compute/docs/disks/customer-supplied-encryption#encrypt_a_new_persistent_disk_with_your_own_keys
- https://cloud.google.com/compute/docs/reference/rest/v1/disks/get
- https://cloud.google.com/compute/docs/disks/customer-supplied-encryption#key_file
Notes
Note 1: When you delete a persistent disk, Google discards the cipher keys, rendering the data irretrievable. This process is irreversible.
Note 2: It is up to you to generate and manage your key. You must provide a key that is a 256-bit string encoded in RFC 4648 standard base64 to Compute Engine.
Note 3: An example key file looks like this.
[
{
"uri": "https://www.googleapis.com/compute/v1/projects/myproject/zones/us- central1-a/disks/example-disk",
"key": "acXTX3rxrKAFTF0tYVLvydU1riRZTvUNC4g5I11NY-c=", "key-type": "raw"
},
{
"uri": "https://www.googleapis.com/compute/v1/projects/myproject/global/snapshots/my -private-snapshot",
"key": "ieCx/NcW06PcT7Ep1X6LUTc/hLvUDYyzSZPPVCVPTVEohpeHASqC8uw5TzyO9U+Fka9JFHz0mBib
XUInrC/jEk014kCK/NPjYgEMOyssZ4ZINPKxlUh2zn1bV+MCaTICrdmuSBTWlUUiFoDD6PYznLwh8 ZNdaheCeZ8ewEXgFQ8V+sDroLaN3Xs3MDTXQEMMoNUXMCZEIpg9Vtp9x2oeQ5lAbtt7bYAAHf5l+g JWw3sUfs0/Glw5fpdjT8Uggrr+RMZezGrltJEF293rvTIjWOEB3z5OHyHwQkvdrPDFcTqsLfh+8Hr 8g+mf+7zVPEC8nEbqpdl3GPv3A7AwpFp7MA=="
"key-type": "rsa-encrypted"
} ]
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
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}
