Cloud Build provides customer-managed encryption keys (CMEK) compliance by encrypting the build-time persistent disk with an ephemeral key that is generated for each build. No configuration is required. The key is uniquely generated for each build.
Once a build starts, the key is accessible only to the build processes requiring it for up to 24 hours. Then, the key is wiped from memory and destroyed.
The key isn't retained anywhere, isn't accessible to Google engineers or support staff, and can't be restored. The data that was protected using such a key is permanently inaccessible once the build completes.
How does the ephemeral key encryption work?
Cloud Build supports CMEK through the use of ephemeral keys, allowing it to be fully consistent and compatible with a CMEK-enabled setup.
Cloud Build does the following to ensure build-time persistent disks are encrypted with an ephemeral key:
Cloud Build mints a random 256-bit encryption key for encrypting each build-time persistent disk.
Cloud Build leverages the Customer-Supplied Encryption Key (CSEK) feature of persistent disk to use this new encryption key as a persistent disk encryption key.
Cloud Build destroys the ephemeral key as soon as the disk is created. The key is never logged or written to any persistent storage and is now irretrievable.
When the build is completed, the persistent disk is deleted, at which point no traces of the key nor the encrypted persistent disk data remain anywhere in Google infrastructure.
When does ephemeral key encryption not apply?
When you create or trigger a build using source mirroring (and not using GitHub triggers), your source code is stored in Cloud Storage or Cloud Source Repositories. You have full control over the code storage location, including control over its encryption.