Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Cloud Build bietet vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK). Dabei wird der nichtflüchtige Speicher für die Build-Dauer mit einem sitzungsspezifischen Schlüssel verschlüsselt, der für jeden Build generiert wird. Es ist keine Konfiguration erforderlich. Für jeden Build wird ein eindeutiger Schlüssel generiert.
Sobald ein Build gestartet wurde, ist der Schlüssel nur für die Build-Prozesse zugänglich, die ihn bis zu 24 Stunden benötigen. Anschließend wird der Schlüssel aus dem Arbeitsspeicher gelöscht und vernichtet.
Der Schlüssel wird nirgendwo gespeichert, ist weder für Google-Entwickler noch für Supportmitarbeiter zugänglich und kann nicht wiederhergestellt werden. Die mit einem solchen Schlüssel geschützten Daten sind nach Abschluss des Builds dauerhaft unzugänglich.
Wie funktioniert die flüchtige Schlüsselverschlüsselung?
Cloud Build unterstützt CMEK durch Verwendung von flüchtigen Schlüsseln. Der Service ist dadurch vollständig mit einer CMEK-fähigen Einrichtung konsistent und kompatibel.
Cloud Build führt die folgenden Schritte aus, damit nichtflüchtige Laufwerke für die Build-Dauer mit einem sitzungsspezifischen Schlüssel verschlüsselt werden:
Cloud Build erstellt einen zufälligen 256-Bit-Verschlüsselungsschlüssel, um jeden nichtflüchtigen Speicher während der Erstellung zu verschlüsseln.
Cloud Build nutzt die Funktion des nichtflüchtigen Speichers für vom Kunden bereitgestellte Verschlüsselungsschlüssel (Customer-Supplied Encryption Key, CSEK), um den neuen Verschlüsselungsschlüssel als Verschlüsselungsschlüssel für den nichtflüchtigen Speicher zu verwenden.
Cloud Build löscht den sitzungsspezifischen Schlüssel, sobald der Datenträger erstellt wurde. Der Schlüssel wird nie protokolliert oder in einen nichtflüchtigen Speicher geschrieben und kann nicht mehr wiederhergestellt werden.
Nach Abschluss des Builds wird der nichtflüchtige Speicher gelöscht. Danach sind weder der Schlüssel noch die verschlüsselten Daten im nichtflüchtigen Speicher in der Google-Infrastruktur zu finden.
Wann erfolgt keine flüchtige Schlüsselverschlüsselung?
Wenn Sie einen Build durch Quellspiegelung (anstatt mit GitHub-Triggern) erstellen oder auslösen, wird der Quellcode in Cloud Storage oder Cloud Source Repositories gespeichert. Sie können den Speicherort für den Code frei wählen und seine Verschlüsselung uneingeschränkt steuern.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (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."]]
