Diese Seite wurde von der Cloud Translation API übersetzt.

Cloud Deploy-Dienstkonten

In diesem Dokument werden Dienstkonten beschrieben, die zum Ausführen von Cloud Deploy und zum Aufrufen von Cloud Deploy zum Ausführen verschiedener Vorgänge verwendet werden.

Cloud Deploy verwendet die folgenden Dienstkonten:

Der Cloud Deploy-Dienst-Agent

Cloud Deploy verwendet dieses Dienstkonto für die Interaktion mit Ihrem Projekt. Sie können diesen Dienst-Agent nicht durch ein alternatives Dienstkonto ersetzen, aber Sie können Berechtigungen dafür bearbeiten, z. B. wenn Sie Ressourcen außerhalb des Projekts verwenden (z. B. ein Dienstkonto oder einen privaten Cloud Build-Worker-Pool).
Das Cloud Deploy-Dienstkonto

Cloud Deploy verwendet dieses Dienstkonto, um Rendering- und Bereitstellungsvorgänge in Cloud Build auszuführen. Dieses Konto benötigt Berechtigungen, um aus dem Cloud Storage-Bucket zu lesen und in diesen zu schreiben und auf Bereitstellungsziele zuzugreifen.

Das Standarddienstkonto für die Ausführung ist das Compute Engine-Standarddienstkonto. In der Zielkonfiguration können Sie ein alternatives Dienstkonto angeben.
Das Cloud Deploy-Automatisierungsdienstkonto

Dies ist das Dienstkonto, das Cloud Deploy für Automatisierungen verwendet. Dies kann das Standard-Ausführungsdienstkonto oder ein anderes Dienstkonto sein. Weitere Informationen zu diesem Dienstkonto finden Sie unter Das Automatisierungsdienstkonto.

Eine Anleitung zum Bearbeiten von Dienstkontoberechtigungen und zum Erstellen eines alternativen Dienstkontos finden Sie unter Dienstkonten erstellen und verwalten.

Cloud Deploy-Dienst-Agent

Der Cloud Deploy-Dienst-Agent ist ein Dienstkonto, mit dem Cloud Deploy mit anderen Google Cloud-Diensten interagiert, auf denen Cloud Deploy basiert. Zu diesen Diensten gehören Cloud Build-, Pub/Sub- und Cloud-Audit-Logs.

Der Name dieses Dienstkontos folgt diesem Muster:

service-<project-number>@gcp-sa-clouddeploy.iam.gserviceaccount.com

Sie können den Dienst-Agent nicht durch ein alternatives Dienstkonto ersetzen. Möglicherweise müssen Sie jedoch Berechtigungen hinzufügen, um beispielsweise Zugriff auf einen privaten Pool in einem anderen Projekt zu gewähren, das als Teil einer Ausführungsumgebung konfiguriert ist.

Cloud Deploy-Dienstkonto für die Ausführung

Cloud Deploy wird standardmäßig mit dem Compute Engine-Standarddienstkonto ausgeführt.

Der Name dieses Dienstkontos folgt diesem Muster:

[project-number]-compute@developer.gserviceaccount.com

Da dieses Dienstkonto von vielen Produkten verwendet wird, kann es umfassende Berechtigungen haben. Als Best Practice wird empfohlen, die Ausführungsumgebung so zu ändern, dass Cloud Deploy als anderes Dienstkonto ausgeführt wird. Sie können das Ausführungsdienstkonto für jedes Ziel ändern, indem Sie die Attribute executionConfigs.privatePool.serviceAccount oder executionConfigs.defaultPool.serviceAccount in der Zieldefinition verwenden.

Jedes Dienstkonto, das Sie für diese Attribute festlegen, muss die Rolle Cloud Deploy Runner im Cloud Deploy-Projekt haben. Wenn das Standardausführungsdienstkonto diese Rolle nicht hat, führen Sie den folgenden Befehl aus:

 gcloud projects add-iam-policy-binding PROJECT_ID \
     --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
     --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
     --role="roles/clouddeploy.jobRunner"

Das Dienstkonto benötigt außerdem laufzeitspezifische Berechtigungen für die Bereitstellung in der ausgewählten Laufzeit. Für die Google Kubernetes Engine können Sie die Rollen Container-Entwickler und Dienstkontonutzer auswählen. Für Cloud Run können Sie die Rollen Cloud Run-Entwickler und Dienstkontonutzer auswählen. Für andere Laufzeiten, die von benutzerdefinierten Zielvorhaben verwendet werden, sind möglicherweise eigene Berechtigungen erforderlich.

Welche Dienstkonten erstellt werden sollen

Wenn Sie nicht das Standardausführungsdienstkonto für das Rendering und die Bereitstellung verwenden, müssen Sie ein oder mehrere alternative Dienstkonten erstellen. Dies sind Dienstkonten, mit denen Cloud Deploy ausgeführt wird und sie sind in der Zielkonfiguration konfiguriert.

Ein Grund zum Erstellen mehrerer Instanzen wäre, dass Sie ein bestimmtes Dienstkonto oder Konten für die Bereitstellung in eingeschränkten Zielen wie einem Produktionsziel haben.

Ein möglicher Ansatz ist die Verwendung separater Dienstkonten pro Bereitstellungspipeline. Jedes dieser Dienstkonten würde Rollen mit ausreichenden Berechtigungen zum Rendern und Bereitstellen umfassen.

Bei Bereitstellungen in der Google Kubernetes Engine können Sie das Dienstkonto auf einen Namespace beschränken.

Dienstkonten aus einem anderen Projekt verwenden

Für Ihre Ausführungsumgebung können Sie ein Dienstkonto in einem anderen Projekt angeben als dem, in dem Sie das Ziel erstellen:

Aktivieren Sie im Projekt, zu dem das Dienstkonto gehört, die projektübergreifende Organisationsrichtlinie für Dienstkonten.
Gewähren Sie dem Cloud Deploy-Dienstagenten (service-<project-number>@gcp-sa-clouddeploy.iam.gserviceaccount.com) die Berechtigung iam.serviceAccounts.actAs für Ihr Dienstkonto.

In diesem Fall ist project-number das Projekt, in dem Sie das Ziel erstellt haben.

Sie können die Rolle roles/iam.serviceAccountUser, die diese Berechtigung enthält, auch im Projekt und für jedes Dienstkonto gewähren, das sich in einem anderen Projekt als dem befindet, in dem Cloud Deploy ausgeführt wird.
Weisen Sie dem Cloud Build-Dienst-Agent (service-<project-number>@gcp-sa-cloudbuild.iam.gserviceaccount.com) die Rolle roles/iam.serviceAccountTokenCreator zu.

In diesem Fall ist project-number das Projekt, in dem Sie das Ziel erstellt haben, und diese Rolle wird im Projekt des Dienstkontos gewährt.

Sie müssen diese Rolle jedem Dienstkonto zuweisen, das in der Ausführungsumgebung eines Ziels konfiguriert ist, wenn sich dieses Dienstkonto in einem anderen Projekt als dem befindet, in dem Cloud Deploy ausgeführt wird.
Gewähren Sie dem Aufrufer von gcloud deploy releases create und gcloud deploy rollouts create die Berechtigung iam.serviceAccounts.actAs für das Dienstkonto oder die Rolle roles/iam.serviceAccountUser.

Erforderliche Berechtigungen

Das für Renderingkonfigurationen verwendete Dienstkonto muss ausreichende Berechtigungen für den Zugriff auf den Cloud Storage-Bucket haben, in dem Ihre Cloud Deploy-Ressourcen gespeichert sind (Zustellungspipelines, Releases, Rollouts).

Die Rolle roles/clouddeploy.jobRunner enthält alle Berechtigungen, die das Renderingdienstkonto (privatePool oder defaultPool) benötigt.
Das für die Bereitstellung verwendete Dienstkonto muss ausreichende Berechtigungen für die Bereitstellung im Zielcluster und die Berechtigung für den Zugriff auf den Cloud Storage-Bucket haben.

Hinweis: Wenn Sie einen benutzerdefinierten Cloud Storage-Bucket verwenden, können Sie ihn an einem beliebigen Ort speichern. (Er muss sich nicht in derselben Region befinden, z. B. wie die Bereitstellungspipeline.)
Das Dienstkonto, das Cloud Deploy zum Erstellen eines Release aufruft, muss die Rolle clouddeploy.releaser haben. Außerdem benötigt er die Berechtigung iam.serviceAccount.actAs, um das Dienstkonto zu verwenden, das Manifeste rendert (z. B. über die Rolle roles/iam.serviceAccountUser).
Das Dienstkonto, das Cloud Deploy aufruft, um einen Release hochzustufen oder einen rollout zu erstellen, muss die Berechtigung iam.serviceAccount.actAs haben, um das Dienstkonto zu verwenden, das in Ziele bereitgestellt wird (z. B. über die Rolle roles/iam.serviceAccountUser).
Das für eine Automatisierung konfigurierte Dienstkonto muss Berechtigungen zum Ausführen der automatisierten Vorgänge haben. Weitere Informationen

Das Automatisierungsdienstkonto

Sie können einige Aktionen in einem Release automatisieren. Cloud Deploy führt diese Automatisierungen mit dem Automatisierungsdienstkonto aus. Das kann das Standardausführungsdienstkonto, ein anderes Dienstkonto, das als Ausführungsdienstkonto verwendet wird, oder ein anderes Dienstkonto sein.

Weitere Informationen zum Automatisierungsdienstkonto.