Quando um build é iniciado, a chave só fica acessível aos processos de build
que a exigem por até 24 horas. Em seguida, a chave é apagada da memória e
destruída.
A chave não é retida em nenhum lugar, não pode ser acessada por engenheiros do Google nem pela equipe de suporte
e não pode ser restaurada. Os dados que foram protegidos usando essa chave ficam
permanentemente inacessíveis após a conclusão do build.
Como funciona a criptografia de chave efêmera?
O Cloud Build é compatível com o CMEK por meio do uso de chaves efêmeras, o que o torna totalmente consistente e compatível com uma configuração ativada para o CMEK.
O Cloud Build faz o seguinte para garantir que os discos permanentes
sejam criptografados com uma chave temporária:
O Cloud Build gera uma chave de criptografia aleatória de 256 bits
para criptografar cada disco permanente de tempo de build.
O Cloud Build aproveita o recurso de chave de criptografia fornecida pelo cliente (CSEK)
do disco persistente para usar essa nova chave de criptografia como uma chave de
criptografia de disco persistente.
O Cloud Build destrói a chave temporária assim que o disco é
criado. A chave nunca é registrada nem gravada em armazenamento persistente e, assim, é
irrecuperável.
Quando a build é concluída, o disco permanente é excluído. Nesse ponto, não há rastros da chave nem dos dados do disco permanente criptografado em nenhum lugar
na infraestrutura do Google.
Quando a criptografia de chave efêmera não se aplica?
Quando você cria ou aciona um build usando o espelhamento de origem (e não os gatilhos do GitHub), o código-fonte é armazenado no Cloud Storage ou no Cloud Source Repositories. Você tem controle total sobre o local de armazenamento do código, incluindo o controle sobre sua criptografia.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-01 UTC."],[[["\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."]]
