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 verwendet werden und Cloud Deploy aufrufen, um verschiedene Vorgänge auszuführen.

Cloud Deploy verwendet die folgenden Dienstkonten:

Der Cloud Deploy-Dienst-Agent

Cloud Deploy verwendet dieses Dienstkonto für die Interaktion mit Ihrem Projekt arbeiten. 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 Dienstkonto für die Cloud Deploy-Automatisierung

Dies ist das Dienstkonto, das Cloud Deploy verwendet, um automations. Das kann die Standardausführung Dienstkonto oder ein anderes Dienstkonto. Weitere Informationen finden Sie unter Das Dienstkonto für die Automatisierung Weitere Informationen zu diesem Dienstkonto.

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, das von Cloud Deploy verwendet, um mit anderen Google Cloud-Diensten von Cloud Deploy zu interagieren auf die Sie sich verlassen. 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.

Dienstkonto für die Cloud Deploy-Ausführung

Cloud Deploy wird standardmäßig mit der Compute Engine-Standardversion ausgeführt. Dienstkonto. Das Dienstkonto verfügt über ausreichende Berechtigungen in dem Projekt, das es zum Rendern von Manifesten und zum Bereitstellen auf Ihren Zielen enthält.

Der Name dieses Dienstkontos folgt diesem Muster:

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

Dieses Standarddienstkonto hat umfassende Berechtigungen. Am besten Ihre Ausführungsumgebung ändern, sodass 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 roles/clouddeploy.jobRunner im Cloud Deploy-Projekt haben. Wenn das Standardausführungsdienstkonto diese Berechtigung 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"

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. Sie sind in der Zielkonfiguration konfiguriert sind.

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 Geben Sie ein Dienstkonto an, das sich in einem anderen Projekt als dem befindet, in dem erstellen Sie das Ziel:

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

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

Sie können auch die roles/iam.serviceAccountUser Rolle, die diese Berechtigung umfasst, im Projekt und für jeden Dienst Konto, das sich in einem anderen Projekt befindet Cloud Deploy wird ausgeführt.
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 haben Ihr Ziel erstellt und diese Rolle wird im Dienst gewährt des Kontos.

Sie müssen diese Rolle jedem Dienstkonto zuweisen, das im wenn sich das Dienstkonto in einem anderen Projekt als 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 roles/iam.serviceAccountUser Rolle.

Erforderliche Berechtigungen

Das für Renderingkonfigurationen verwendete Dienstkonto muss genügend Berechtigungen für den Zugriff auf den Cloud Storage-Bucket, in dem sich Ihr Cloud Deploy-Gerät befindet Ressourcen gespeichert werden (Bereitstellungspipelines, Releases, Roll-outs).

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 muss es die iam.serviceAccount.actAs Berechtigung, das Dienstkonto zu verwenden, das Manifeste rendert (z. B. über die roles/iam.serviceAccountUser Rolle).
Das Dienstkonto, das Cloud Deploy aufruft, um einen Release hochzustufen oder zum Erstellen eines rollout benötigen Sie die Berechtigung iam.serviceAccount.actAs für Verwenden Sie das Dienstkonto für die Bereitstellung in Zielen (z. B. über die roles/iam.serviceAccountUser Rolle).
Das für eine Automatisierung konfigurierte Dienstkonto muss Berechtigungen zum Ausführen der automatisierten Vorgänge haben. Weitere Informationen

Das Dienstkonto für die Automatisierung

Sie können einige Aktionen in einem Release automatisieren. führt Cloud Deploy diese aus mit dem Automatisierungs-Dienstkonto, das das Standarddienstkonto Ausführungsdienstkonto, ein nicht standardmäßiges Dienstkonto, das für die Ausführung verwendet wird Dienstkonto oder ein anderes Dienstkonto.

Weitere Informationen das Dienstkonto für die Automatisierung.