Using CSEKs means you provide your own encryption keys and Compute Engine uses
your keys to protect the Google-owned and Google-managed encryption 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 (CSEK).
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.
When you delete a Persistent Disk volume, Google discards the cipher keys,
rendering the data irretrievable. This process is irreversible.
If you haven't already, set up authentication.
Authentication verifies your identity for access to Google Cloud services and APIs. To run
code or samples from a local development environment, you can authenticate to
Compute Engine by selecting one of the following options:
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and
APIs, you don't need to set up authentication.
gcloud
Install the Google Cloud CLI.
After installation,
initialize the Google Cloud CLI by running the following command:
To use the Python samples on this page in a local development environment, install and
initialize the gcloud CLI, and then set up Application Default Credentials with
your user credentials.
To get the permissions that
you need to create CSEK-encrypted snapshots, images, and disks,
ask your administrator to grant you the
following IAM roles on the project:
These predefined roles contain
the permissions required to create CSEK-encrypted snapshots, images, and disks. To see the exact permissions that are
required, expand the Required permissions section:
Required permissions
The following permissions are required to create CSEK-encrypted snapshots, images, and disks:
To create a snapshot of a disk:
compute.snapshots.create
on the project
compute.disks.createSnapshot
on the disk
To create an image:
compute.images.create
on the project
compute.disks.useReadOnly
on the disk
To create a disk from a standard snapshot:
compute.disks.create
on the destination project for the new disk
compute.snapshots.useReadOnly
on the snapshot
To create a disk from an image:
compute.disks.create
on the destination project for the new disk
compute.images.useReadOnly
on the image
To create a disk from an instant snapshot:
compute.disks.create
on the destination project for the new disk
compute.instantSnapshots.useReadOnly
on the source instant snapshot
Availability of customer-supplied encryption keys depends on the location of
your billing account, not the location of the resource.
Customer-supplied encryption keys are not available for billing accounts that
are in the following countries:
Brazil
India
Technical restrictions
You can only encrypt new persistent disks with your own key. You
can't encrypt existing persistent disks with your own key.
You can't use your own keys with Local SSD disks
because Local SSD disks use Google-owned and Google-managed encryption keys.
The keys are deleted when the VM is terminated.
You can't suspend instances that have CSEK-protected disks attached.
Specifications
This section describes the encryption specification and the format of CSEK.
Encryption
Compute Engine uses your encryption key to protect Google's
encryption keys with AES-256 encryption.
Required key format
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.
The following is an example of a base64 encoded key, generated with the string
"Hello from Google Cloud Platform"
In addition to encoding your key in base64, you can optionally wrap
your key using an RSA public key certificate provided by Google, encode the key
in base64, and then use that key in your requests.
RSA wrapping is a process in which you use a public key to encrypt your data.
After that data has been encrypted with the public key, it can only be
decrypted by the respective private key. In this case, the private key is known
only to Google Cloud services. By wrapping your key using the RSA
certificate, you ensure that only Google Cloud services can unwrap your
key and use it to protect your data.
To create an RSA-wrapped key for Compute Engine, do the following:
Wrap your key using the public key provided in a certificate that
Compute Engine manages. Make sure to wrap your key using OAEP
padding, not PKCS #1 v1.5 padding.
Encode your RSA-wrapped key using standard base64 encoding.
Download the public certificate maintained by Compute Engine from:
There are many ways of generate and RSA-wrap your key; use a method that is
familiar to you. The following are two examples of RSA-wrapping your key that
you could use.
Example 1
The following instructions use the
openssl
command-line utility to RSA-wrap and encode a key.
Optional: Generate a 256-bit (32-byte) random key. If you already have
a key you want to use, you can skip this step. There are many ways you can
generate a key. For example:
The following is sample Python script that generates a 256-bit (32-byte) random
string and creates a base64 encoded RSA-wrapped key using the
cryptography
library:
importargparseimportbase64importosfromtypingimportOptionalfromcryptographyimportx509fromcryptography.hazmat.backendsimportdefault_backendfromcryptography.hazmat.primitivesimporthashesfromcryptography.hazmat.primitives.asymmetricimportpaddingfromcryptography.hazmat.primitives.asymmetric.rsaimportRSAPublicKeyimportrequestsGOOGLE_PUBLIC_CERT_URL=("https://cloud-certs.storage.googleapis.com/google-cloud-csek-ingress.pem")defget_google_public_cert_key()-> RSAPublicKey:""" Downloads the Google public certificate. Returns: RSAPublicKey object with the Google public certificate. """r=requests.get(GOOGLE_PUBLIC_CERT_URL)r.raise_for_status()# Load the certificate.certificate=x509.load_pem_x509_certificate(r.content,default_backend())# Get the certicate's public key.public_key=certificate.public_key()returnpublic_keydefwrap_rsa_key(public_key:RSAPublicKey,private_key_bytes:bytes)-> bytes:""" Use the Google public key to encrypt the customer private key. This means that only the Google private key is capable of decrypting the customer private key. Args: public_key: The public key to use for encrypting. private_key_bytes: The private key to be encrypted. Returns: private_key_bytes encrypted using the public_key. Encoded using base64. """wrapped_key=public_key.encrypt(private_key_bytes,padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA1()),algorithm=hashes.SHA1(),label=None,),)encoded_wrapped_key=base64.b64encode(wrapped_key)returnencoded_wrapped_keydefmain(key_file:Optional[str])-> None:""" This script will encrypt a private key with Google public key. Args: key_file: path to a file containing your private key. If not provided, a new key will be generated (256 bit). """# Generate a new 256-bit private key if no key is specified.ifnotkey_file:customer_key_bytes=os.urandom(32)else:withopen(key_file,"rb")asf:customer_key_bytes=f.read()google_public_key=get_google_public_cert_key()wrapped_rsa_key=wrap_rsa_key(google_public_key,customer_key_bytes)b64_key=base64.b64encode(customer_key_bytes).decode("utf-8")print(f"Base-64 encoded private key: {b64_key}")print(f"Wrapped RSA key: {wrapped_rsa_key.decode('utf-8')}")if__name__=="__main__":parser=argparse.ArgumentParser(description=__doc__,formatter_class=argparse.RawDescriptionHelpFormatter)parser.add_argument("--key_file",help="File containing your binary private key.")args=parser.parse_args()main(args.key_file)
Your key is now ready to use!
Use a RSA-wrapped key
Using the Google Cloud CLI, you can provide a regular key and a
RSA-wrapped key in the same way.
In the API, use the
sha256 property instead of rawKey if you want to use a
RSA-wrapped key instead.
Encrypting resources with CSEK using the command-line tool
Encryption keys can be used through the Google Cloud CLI.
When you use the gcloud compute command-line tool to set your keys,
you provide encoded keys using a key file that contains your encoded keys as
a JSON list. A key file can contain multiple keys, letting you manage many
keys in a single place. Alternatively, you can create single key files to
handle each key separately. A key file is only usable with the gcloud CLI.
When using REST, you must supply the key directly in your request.
Each entry in your key file must provide:
The fully qualified URI to the resource the key protects
The corresponding key
The type of key, either raw or rsa-encrypted
When you use the key file in your requests, the tool looks for matching
resources and uses the respective keys. If no matching resources are
found, the request fails.
If you use a key file, restrict access to your file to only those
who need it. Make sure to set appropriate permissions on these files and
consider encrypting these files using additional tools:
If you create a snapshot from a CSEK-encrypted disk, you must provide
the encryption key that you used to encrypt the disk and a key to encrypt
the new snapshot. You must also encrypt the snapshot with a CSEK.
To convert CSEK-encrypted disks or snapshots to use Google-owned and Google-managed encryption keys,
you must create a new disk or snapshot.
Snapshots of disks encrypted with CSEK are always full snapshots. This differs
from snapshots of disks encrypted with customer-managed encryption keys
(CMEK), which are
incremental. Snapshots are priced based
on the total size of the snapshot, so a full snapshot might cost more than an
incremental snapshot.
Create a new image from a disk or custom image encrypted with CSEK
You can create custom images from encrypted persistent disks or copy encrypted
images. You cannot use the console to copy images. Use the
Google Cloud CLI or REST to copy images.
Import the custom Compute Engine image that you want to encrypt.
Specify the URI to the compressed file and also specify a path to your
encryption key file.
Create resources that have different encryption types
You can create instances and other resources that use a mix of CSEK-, CMEK-, and
Google-owned and managed key-encrypted
resources. For example, you can create an instance that has a CSEK-encrypted boot
disk and a CMEK-encrypted data disk.
To create such resources in a single request with the Google Cloud CLI,
you must include the --no-require-csek-key-create flag in your request.
You must still specify the CSEK key for any CSEK-encrypted resources with the
--csek-key-file flag. When you provide both flags,
Compute Engine creates any customer-encrypted resources that are explicitly
defined in your key file and also creates any standard resources you specify.
For example, assume a key file contains the following:
You can simultaneously create two instances, one with a boot disk
that's encrypted with a CSEK and the other with a boot disk encrypted with a
Google-owned and managed key with the following command:
Normally, it wouldn't be possible to create example-disk-2 if you
specified the --csek-key-file flag because the disk is not explicitly defined
in the key file. By adding the --no-require-csek-key-create, both disks are
created, one encrypted using the key file, and the other encrypted using
Google-owned and managed keys.
Remove your CSEK from a Persistent Disk
You can decrypt the contents of a customer-encrypted disk and create a new disk
that uses Google-owned and managed keys instead.
After you create the new persistent disk, Compute Engine uses
Google-owned and managed keys to protect the disk contents.
Any snapshots that you create from that disk must also use
Google-owned and managed keys
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-10-05 UTC."],[],[]]
