[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],[],[[["\u003cp\u003eCustomer-supplied encryption keys (CSEKs) are used in Cloud Storage and Compute Engine to protect Google-generated keys that encrypt and decrypt user data.\u003c/p\u003e\n"],["\u003cp\u003eIn Cloud Storage, raw CSEKs wrap chunk keys, which in turn wrap raw chunk keys that encrypt data chunks stored in storage systems.\u003c/p\u003e\n"],["\u003cp\u003eIn Compute Engine, a CSEK-derived key, generated from the raw CSEK and a nonce, wraps raw disk keys, which are used to encrypt disk data, and can also utilize RSA-wrapped keys.\u003c/p\u003e\n"],["\u003cp\u003eRaw CSEKs, CSEK-derived keys, and raw disk keys are never stored unencrypted on disk and are protected using access management and cryptographic privacy measures while in memory or in transit.\u003c/p\u003e\n"],["\u003cp\u003eThe document outlines the key wrapping process, the purpose of various keys (raw CSEK, wrapped chunk keys, raw chunk keys, etc.), and how these keys are protected within Google Cloud's infrastructure for both Cloud Storage and Compute Engine.\u003c/p\u003e\n"]]],[],null,["# Customer-supplied encryption keys\n\n***This content was last updated in February 2025 and represents the status quo\nas of the time that it was written. Google's security policies and systems may\nchange going forward, as we continually improve protection for our customers***.\n\nCustomer-supplied encryption keys (CSEK) are a feature in\n[Cloud Storage](/storage) and\n[Compute Engine](/compute). If you supply your own\nencryption keys, Google uses your key to protect the Google generated keys that\nencrypt and decrypt your data.\n\nThis document describes how CSEKs work and how they are protected in\nGoogle Cloud.\n\nHow CSEKs work with Cloud Storage\n---------------------------------\n\nWhen you use CSEKs in Cloud Storage, the following keys are part of the\nwrapping process:\n\n- **Raw CSEK:** You provide a raw CSEK as part of an API call. The raw CSEK key is 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 your data.\n- **Wrapped chunk keys:** The raw CSEK is used to wrap the wrapped chunk keys.\n- **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 the storage systems. These keys are used as the data encryption keys (DEKs) in Cloud Storage for your data.\n\nThe following diagram shows the key wrapping process.\n\nThe following table describes the keys.\n\nHow CSEKs work with Compute Engine\n----------------------------------\n\nWhen you use CSEKs in Compute Engine, the following keys are part of the\nwrapping process:\n\n- **Raw CSEK:** You provide a raw CSEK or an [RSA-wrapped\n key](/compute/docs/disks/customer-supplied-encryption#rsa-encryption) as part of an API call. The CSEK is transmitted from the GFE to the internal cluster manager's front end. The cluster manager is a collection of processes running under a cluster manager identity in Google's production infrastructure that implements the logic for managing Compute Engine resources such as disks and VM instances.\n- **Google-owned asymmetric wrapping key:** If an RSA-wrapped key is provided as the CSEK, then the key is unwrapped using a Google-owned asymmetric wrapping key.\n- **CSEK-derived key:** The raw CSEK is combined with a per-persistent disk\n cryptographic nonce to generate a CSEK-derived key. This key is used as the\n KEK in Compute Engine for your data. In the cluster manager front\n end, both the CSEK and the CSEK-derived key are kept only in the cluster\n manager memory. The CSEK-derived key is used in the cluster manager memory to\n unwrap the wrapped disk keys which are stored in the cluster manager instance\n metadata and instance manager metadata, when automatic restart is enabled\n (this metadata is not the same as the [instance\n metadata](/compute/docs/storing-retrieving-metadata)).\n\n- **Raw disk keys:** The CSEK-derived key is used to wrap raw disk keys when\n creating a disk and to unwrap raw disk keys when accessing a disk. The\n following events occur:\n\n - If automatic restart is enabled, the wrapped disk keys are stored persistently by the cluster manager for the lifespan of the VM so that the VM can be restarted in the event of a crash. The wrapped disk keys are wrapped with a Google-owned symmetric wrapping key. The permissions of the wrapping key allow it to be used only by Compute Engine. If automatic restart is turned off, the wrapped disk keys are deleted using the deletion process that is described in [Data deletion on\n Google Cloud](/docs/security/deletion).\n - If live migration is enabled, the raw disk key is passed from the old VM instance memory to the new VM instance memory without the instance manager or cluster manager being involved in the key copy.\n\nThe raw disk keys are passed to the memory of the cluster manager (CM), instance\nmanager, and VM. These keys are used as the DEKs in Compute Engine for\nyour data.\n\nThe following diagram shows how key wrapping works.\n\nHow CSEKs are protected\n-----------------------\n\nThis section provides information on how CSEKs are protected on disk, as they\nmove around the Google Cloud infrastructure, and in memory.\n\nRaw CSEKs, CSEK-derived keys, and raw disk keys are never stored on disk\nunencrypted. Raw disk keys are stored wrapped with CSEK-derived keys and with\nGoogle keys when automatic restart is used. Google doesn't permanently store\nyour keys on its servers.\n\nEach service uses access management features provided by the infrastructure to\nspecify exactly which other services can communicate with it. The service is\nconfigured with the allowlist of the allowed service account identities, and\nthis access restriction is then automatically enforced by Google Cloud\ninfrastructure. For more information, see [service identity, integrity, and\nisolation](/security/security-design#service_identity_integrity_and_isolation).\n\nThe infrastructure also provides cryptographic privacy and integrity for RPC\ndata on the network. Services can configure the level of cryptographic\nprotection they want for each infrastructure RPC, and these are enabled for\nCSEKs. For more information, see [Encryption of inter-workload\ncommunication](/docs/security/infrastructure/design#encryption-inter-service).\n\nKey material lives in various systems' memory, including cluster manager memory\nand VMM memory. Access to these systems' memory is by exception (for example, as\npart of an incident) and managed by access control lists. These systems have\nmemory dumps disabled or automatically scan for key material in memory dumps.\nFor information about protections to these jobs, see [How Google protects its\nproduction\nservices](/docs/security/production-services-protection).\n\nWhat's next\n-----------\n\n- [Customer-supplied encryption keys in\n Cloud Storage](/storage/docs/encryption/customer-supplied-keys)\n\n- [Customer-supplied encryption keys in\n Compute Engine](/compute/docs/disks/customer-supplied-encryption)"]]