This content was last updated in February 2025 and represents the status quoas of the time that it was written. Google's security policies and systems maychange going forward, as we continually improve protection for our customers.

Customer-supplied encryption keys (CSEK) are a feature inCloud Storage andCompute Engine. If you supply your ownencryption keys, Google uses your key to protect the Google generated keys thatencrypt and decrypt your data.

This document describes how CSEKs work and how they are protected inGoogle Cloud.

How CSEKs work with Cloud Storage

When you use CSEKs in Cloud Storage, the following keys are part of thewrapping process:

• Raw CSEK: You provide a raw CSEK as part of an API call. The raw CSEK keyis transmitted from the Google Front End (GFE) to the storage system's memory.This key is the key encryption key (KEK) in Cloud Storage for yourdata.
• Wrapped chunk keys: The raw CSEK is used to wrap the wrapped chunk keys.
• Raw chunk keys: The wrapped chunk keys wrap the raw chunk keys in memory.The raw chunk keys are used to encrypt the data chunks that are stored in thestorage systems. These keys are used as the data encryption keys (DEKs) inCloud Storage for your data.

The following diagram shows the key wrapping process.

The following table describes the keys.

How CSEKs work with Compute Engine

When you use CSEKs in Compute Engine, the following keys are part of thewrapping process:

• Raw CSEK: You provide a raw CSEK or anRSA-wrappedkeyas part of an API call. The CSEK is transmitted from the GFE to the internalcluster manager's front end. The cluster manager is a collection of processesrunning under a cluster manager identity in Google's production infrastructurethat implements the logic for managing Compute Engine resources suchas disks and VM instances.
• Google-owned asymmetric wrapping key: If an RSA-wrapped key is provided asthe CSEK, then the key is unwrapped using a Google-owned asymmetric wrappingkey.

• CSEK-derived key: The raw CSEK is combined with a per-persistent diskcryptographic nonce to generate a CSEK-derived key. This key is used as theKEK in Compute Engine for your data. In the cluster manager frontend, both the CSEK and the CSEK-derived key are kept only in the clustermanager memory. The CSEK-derived key is used in the cluster manager memory tounwrap the wrapped disk keys which are stored in the cluster manager instancemetadata and instance manager metadata, when automatic restart is enabled(this metadata is not the same as theinstancemetadata).

• Raw disk keys: The CSEK-derived key is used to wrap raw disk keys whencreating a disk and to unwrap raw disk keys when accessing a disk. Thefollowing events occur:

  • If automatic restart is enabled, the wrapped disk keys are storedpersistently by the cluster manager for the lifespan of the VM so that theVM can be restarted in the event of a crash. The wrapped disk keys arewrapped with a Google-owned symmetric wrapping key. The permissions of thewrapping key allow it to be used only by Compute Engine. Ifautomatic restart is turned off, the wrapped disk keys are deleted using thedeletion process that is described inData deletion onGoogle Cloud.
  • If live migration is enabled, the raw disk key is passed from the old VMinstance memory to the new VM instance memory without the instance manageror cluster manager being involved in the key copy.

The raw disk keys are passed to the memory of the cluster manager (CM), instancemanager, and VM. These keys are used as the DEKs in Compute Engine foryour data.

The following diagram shows how key wrapping works.

How CSEKs are protected

This section provides information on how CSEKs are protected on disk, as theymove around the Google Cloud infrastructure, and in memory.

Raw CSEKs, CSEK-derived keys, and raw disk keys are never stored on diskunencrypted. Raw disk keys are stored wrapped with CSEK-derived keys and withGoogle keys when automatic restart is used. Google doesn't permanently storeyour keys on its servers.

Each service uses access management features provided by the infrastructure tospecify exactly which other services can communicate with it. The service isconfigured with the allowlist of the allowed service account identities, andthis access restriction is then automatically enforced by Google Cloudinfrastructure. For more information, seeservice identity, integrity, andisolation.

The infrastructure also provides cryptographic privacy and integrity for RPCdata on the network. Services can configure the level of cryptographicprotection they want for each infrastructure RPC, and these are enabled forCSEKs. For more information, seeEncryption of inter-workloadcommunication.

Key material lives in various systems' memory, including cluster manager memoryand VMM memory. Access to these systems' memory is by exception (for example, aspart of an incident) and managed by access control lists. These systems havememory dumps disabled or automatically scan for key material in memory dumps.For information about protections to these jobs, seeHow Google protects itsproductionservices.

What's next

• Customer-supplied encryption keys inCloud Storage

• Customer-supplied encryption keys inCompute Engine