[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-18。"],[[["\u003cp\u003eCloud Build encrypts each build-time persistent disk with a unique, randomly generated 256-bit ephemeral key, ensuring CMEK compliance without requiring user configuration.\u003c/p\u003e\n"],["\u003cp\u003eThe ephemeral key is accessible only to the build processes for up to 24 hours, after which it is wiped from memory and destroyed, making it inaccessible and irretrievable.\u003c/p\u003e\n"],["\u003cp\u003eCloud Build leverages the Customer-Supplied Encryption Key (CSEK) feature to use the ephemeral key for persistent disk encryption, and then destroys the key immediately after the disk is created.\u003c/p\u003e\n"],["\u003cp\u003eUpon completion of the build, the persistent disk is deleted, leaving no traces of the key or encrypted data within Google infrastructure.\u003c/p\u003e\n"],["\u003cp\u003eSource code storage in Cloud Storage or Cloud Source Repositories, through source mirroring, does not utilize ephemeral key encryption, instead giving the user full control over the encryption settings.\u003c/p\u003e\n"]]],[],null,["# CMEK compliance in Cloud Build\n\nCloud Build provides [customer-managed encryption keys (CMEK)\ncompliance](/kms/docs/cmek#cmek_compliance) by encrypting the build-time\npersistent disk with an ephemeral key that is generated for each build. No\nconfiguration is required. The key is uniquely generated for each build.\n\nOnce a build starts, the key is accessible only to the build processes\nrequiring it for up to 24 hours. Then, the key is wiped from memory and\ndestroyed.\n\nThe key isn't retained anywhere, isn't accessible to Google engineers or support\nstaff, and can't be restored. The data that was protected using such a key is\npermanently inaccessible once the build completes.\n\nHow does the ephemeral key encryption work?\n-------------------------------------------\n\nCloud Build supports CMEK through the use of ephemeral keys, allowing\nit to be fully consistent and compatible with a CMEK-enabled setup.\n\nCloud Build does the following to ensure build-time persistent disks\nare encrypted with an ephemeral key:\n\n1. Cloud Build mints a random 256-bit encryption key\n for encrypting each build-time persistent disk.\n\n2. Cloud Build leverages the Customer-Supplied Encryption Key (CSEK)\n feature of persistent disk to use this new encryption key as a persistent\n disk encryption key.\n\n3. Cloud Build destroys the ephemeral key as soon as the disk is\n created. The key is never logged or written to any persistent storage and is\n now irretrievable.\n\n4. When the build is completed, the persistent disk is deleted, at which point\n no traces of the key nor the encrypted persistent disk data remain anywhere\n in Google infrastructure.\n\nWhen does ephemeral key encryption not apply?\n---------------------------------------------\n\nWhen you create or trigger a build using source mirroring (and not using\nGitHub triggers), your source code is stored in Cloud Storage\nor Cloud Source Repositories. You have full control over the code storage\nlocation, including control over its encryption."]]