Änderung des Cloud Build-Standarddienstkontos

Cloud Build wählt automatisch das Cloud Build-Dienstkonto aus, um Builds für Sie auszuführen, sofern Sie dieses Verhalten nicht überschreiben. Dieses Standarddienstkonto hat möglicherweise Berechtigungen, die für Ihren Anwendungsfall unnötig umfassend sind, z. B. Zugriff auf alle Cloud Storage-Bucket in Ihrem Projekt.

Das Standardverhalten für die Verwendung von Dienstkonten durch Cloud Build in neuen Projekten wurde im Mai und Juni 2024 über mehrere Wochen hinweg geändert. Diese Änderungen verbessern den standardmäßigen Sicherheitsstatus unserer Kunden. Sie können diese Änderungen deaktivieren, indem Sie die Einschränkung für Organisationsrichtlinien konfigurieren.

Vor dieser Änderung hat Cloud Build standardmäßig ein Cloud Build-spezifisches Dienstkonto verwendet, das jetzt als Cloud Build-Legacy-Dienstkonto bezeichnet wird.

Nach dieser Änderung verwendet Cloud Build jetzt das Compute Engine-Standarddienstkonto als Standarddienstkonto.

Wie sich die Änderungen auf Ihre Projekte auswirken, hängt davon ab, ob Sie Teil einer Organisation sind:

  • Projekte ohne Organisation Wenn Sie den ersten Build in Ihrem Projekt nach der Änderung ausführen, wird für dieses Projekt standardmäßig das Compute Engine-Dienstkonto für Builds verwendet, die über die Cloud Build API oder die Google Cloud CLI eingereicht werden. In diesen Projekten ist es nicht möglich, das Cloud Build-Legacy-Dienstkonto zu verwenden. Sie können aber ein vom Nutzer angegebenes Dienstkonto verwenden.

  • Projekte mit einer Organisation. Wenn Sie den ersten Build in Ihrem Projekt nach der Änderung ausführen, wird für dieses Projekt standardmäßig das Compute Engine-Dienstkonto für Builds verwendet, die über die Cloud Build API oder die Google Cloud CLI eingereicht werden. Sie können ein nutzerdefiniertes Dienstkonto verwenden oder die Änderung ablehnen, indem Sie das Cloud Build-Dienstkonto in Ihrer Organisation aktivieren.

  • Vorhandene Projekte ohne Organisation Wenn Sie den ersten Build in Ihrem Projekt vor der Änderung ausgeführt haben, wird für dieses Projekt weiterhin das alte Verhalten verwendet und für alle Ihre Builds wird standardmäßig das alte Cloud Build-Dienstkonto verwendet. Sie können weiterhin ein nutzerdefiniertes Dienstkonto verwenden, indem Sie entweder das Compute Engine-Dienstkonto auswählen oder ein eigenes erstellen.

  • Vorhandene Projekte mit einer Organisation Wenn Sie den ersten Build in Ihrem Projekt vor der Änderung ausgeführt haben, wird für dieses Projekt weiterhin das alte Verhalten verwendet und standardmäßig das Cloud Build-Legacy-Dienstkonto verwendet. Sie können auch weiterhin ein nutzerdefiniertes Dienstkonto verwenden.

  • Trigger Sie müssen ein Dienstkonto angeben, wenn Sie einen Trigger erstellen oder aktualisieren, es sei denn, das Standarddienstkonto für Ihr Projekt ist das alte Cloud Build-Dienstkonto.

  • Name des Cloud Build-Dienstkontos: Das Cloud Build-Dienstkonto wird als Legacy-Cloud Build-Dienstkonto bezeichnet.

Was muss ich tun?

Wenn Sie Teil einer Organisation sind, kann Ihre Organisation das Verhalten aller Projekte konfigurieren, indem sie eine Organisationsrichtlinie mit den ausgewählten Einschränkungen einrichtet.

Ihre Organisation kann diese Änderungen deaktivieren, indem sie die folgenden booleschen Einschränkungen für Organisationsrichtlinien festlegt:

  • Nicht erzwungen: constraints/cloudbuild.disableCreateDefaultServiceAccount
  • Nicht erzwungen: constraints/cloudbuild.useComputeServiceAccount
  • Erzwungen: constraints/cloudbuild.useBuildServiceAccount

Wenn Sie die Organisationsrichtlinie nicht anpassen können oder möchten und die Cloud Build API nach der Änderung aktivieren, prüfen Sie, ob das Compute Engine-Standarddienstkonto oder Ihr nutzererstelltes Dienstkonto genügend Berechtigungen für Ihren Build hat. Insbesondere muss der Nutzer, der den Build einreicht, die Berechtigung iam.serviceAccounts.actAs für das Dienstkonto haben.

Neue Einschränkungen für Organisationsrichtlinien

In Cloud Build wurden neue boolesche Einschränkungen für Organisationsrichtlinien eingeführt, die konfiguriert werden können:

  • Die Möglichkeit, das alte Cloud Build-Dienstkonto zu verwenden.
  • Das Standarddienstkonto für alle Projekte in einer Organisation.

Sie können Organisationsrichtlinien in der Google Cloud -Konsole oder mit der Google Cloud CLI ändern:

Weitere Informationen zu Organisationsrichtlinien finden Sie unter Einführung in den Organisationsrichtliniendienst.

Verfügbarkeit des alten Cloud Build-Dienstkontos konfigurieren

Wenn Sie die Cloud Build API aktivieren, wird die folgende boolesche Richtlinieneinschränkung eingeführt, um die Verfügbarkeit des alten Cloud Build-Dienstkontos zu konfigurieren:

  • Nicht erzwungen: constraints/cloudbuild.disableCreateDefaultServiceAccount. Ermöglicht die Verwendung des Cloud Build-Legacy-Dienstkontos in neuen Projekten.

  • Erzwungen: constraints/cloudbuild.disableCreateDefaultServiceAccount. Deaktiviert die Verwendung des Cloud Build-Legacy-Dienstkontos in neuen Projekten. Dies ist der Standardwert der Einschränkung.

Diese Einschränkung betrifft nur Projekte, in denen der erste Build nach der Einführung der Änderung ausgeführt wird. Wenn Sie sich entscheiden, die Richtlinieneinschränkung nicht zu erzwingen, ist die Änderung dauerhaft für alle Projekte, für die der erste Build ausgeführt wird, wenn diese Konfiguration aktiv ist. Sie können die Verfügbarkeit des Cloud Build-Legacy-Dienstkontos in einem Projekt, in dem das Dienstkonto zuvor verfügbar war, nicht deaktivieren. Auch wenn das Dienstkonto verfügbar ist, können Sie verhindern, dass Nutzer in Ihrer Organisation es verwenden. Das wird im nächsten Abschnitt beschrieben.

Wie bei allen Organisationsrichtlinien und ‑einschränkungen können Sie diese Richtlinien auf Organisations- oder Projektebene festlegen.

Standarddienstkonto für eine Organisation konfigurieren

Um zu konfigurieren, welches Standarddienstkonto in einer Organisation verwendet wird, führt Cloud Build zwei neue boolesche Richtlinienbeschränkungen ein:

  • constraints/cloudbuild.useBuildServiceAccount: Konfigurieren Sie die Verwendung des alten Cloud Build-Dienstkontos.
  • constraints/cloudbuild.useComputeServiceAccount: Konfigurieren Sie die Verwendung des Compute Engine-Standarddienstkontos.

Sie können diese Richtlinien unabhängig voneinander konfigurieren. Sie sind jedoch am nützlichsten, wenn die Durchsetzungsregeln in den folgenden Szenarien kombiniert werden:

  • Sicherste Option: Verwenden Sie ein nutzerdefiniertes Dienstkonto sowohl für manuell eingereichte als auch für ausgelöste Builds. Dazu müssen Sie die folgenden Einschränkungen in Ihrer Organisationsrichtlinie festlegen:

    • Nicht erzwungen: constraints/cloudbuild.useBuildServiceAccount
    • Nicht erzwungen: constraints/cloudbuild.useComputeServiceAccount

  • Compute Engine-Standarddienstkonto: Wenn Sie das Compute Engine-Standarddienstkonto sowohl für manuell eingereichte als auch für ausgelöste Builds verwenden möchten, legen Sie die folgenden Einschränkungen in Ihrer Organisationsrichtlinie fest:

    • Nicht erzwungen: constraints/cloudbuild.useBuildServiceAccount
    • Erzwungen: constraints/cloudbuild.useComputeServiceAccount

  • Legacy-Dienstkonto von Cloud Build: Wenn Sie sich der damit verbundenen Sicherheitsrisiken bewusst sind, legen Sie die folgenden Einschränkungen in Ihrer Organisationsrichtlinie fest:

    • Nicht erzwungen: constraints/cloudbuild.disableCreateDefaultServiceAccount
    • Nicht erzwungen: constraints/cloudbuild.useComputeServiceAccount
    • Erzwungen: constraints/cloudbuild.useBuildServiceAccount

  • Legacy- und Compute Engine-Standarddienstkonten: Verwenden Sie weiterhin das Cloud Build-Legacy-Dienstkonto für Projekte, für die die Cloud Build API vor der Änderung aktiviert wurde, und verwenden Sie das Compute Engine-Standarddienstkonto für neue Projekte. Wenn Sie sich der damit verbundenen Sicherheitsrisiken bewusst sind, legen Sie die folgenden Einschränkungen in Ihrer Organisationsrichtlinie fest:

    • Erzwungen: constraints/cloudbuild.disableCreateDefaultServiceAccount
    • Erzwungen: constraints/cloudbuild.useComputeServiceAccount
    • Erzwungen: constraints/cloudbuild.useBuildServiceAccount

Richtlinien für IAM-Rollen

Die Organisationsrichtlinie iam.automaticIamGrantsForDefaultServiceAccounts verhindert, dass bestimmten Standarddienstkonten bei der Erstellung die Rolle „Bearbeiter“ (roles/editor) zugewiesen wird. Diese Richtlinie ist seit dem 3. Mai 2024 in Organisationen aktiviert und gilt für Compute Engine- und App Engine-Standarddienstkonten, die am oder nach dem 3. Mai 2024 erstellt wurden. Wir empfehlen, diese Richtlinie aktiviert zu lassen, da die Rolle „Editor“ sehr umfassend ist und mehr Berechtigungen gewährt, als für die meisten Anwendungsfälle erforderlich sind.

Diese Organisationsrichtlinie gilt nicht für das Cloud Build-Legacy-Dienstkonto, da diesem Dienstkonto die Rolle „Bearbeiter“ nicht standardmäßig zugewiesen ist. Dem Cloud Build-Legacy-Dienstkonto wird jedoch standardmäßig die Rolle „Cloud Build-Dienstkonto“ (roles/cloudbuild.builds.builder) zugewiesen, die ebenfalls eine Vielzahl von Berechtigungen umfasst. Wenn Sie das Legacy-Dienstkonto von Cloud Build verwenden, sollten Sie prüfen, ob die Rolle „Cloud Build-Dienstkonto“ für Ihren Anwendungsfall erforderlich ist oder ob Sie sie durch eine Rolle mit weniger Berechtigungen ersetzen können.

Weitere Informationen finden Sie unter Nutzung von IAM-Dienstkonten einschränken und IAM sicher verwenden.

Aktuelles Standarddienstkonto für ein Projekt abrufen

Mit der Google Cloud CLI oder der Cloud Build API können Sie ermitteln, welches Dienstkonto Cloud Build standardmäßig für ein Projekt verwendet:

gcloud-CLI

Führen Sie den folgenden Befehl aus, um das Standarddienstkonto für das aktuelle Projekt abzurufen:

gcloud builds get-default-service-account

Cloud Build API

Rufen Sie die Cloud Build API mit cURL auf:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/defaultServiceAccount

Ersetzen Sie die Platzhalterwerte durch Folgendes: