Benutzerdefinierte Dienstkonten konfigurieren

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite wird erläutert, wie benutzerdefinierte Dienstkonten für Builds konfiguriert werden.

Standardmäßig verwendet Cloud Build Builds mit einem speziellen Dienstkonto. Dieses Dienstkonto wird als Cloud Build-Dienstkonto bezeichnet und automatisch erstellt, wenn Sie die Cloud Build API in einem Google Cloud-Projekt aktivieren. Dieses Dienstkonto hat standardmäßig eine Reihe von Berechtigungen wie z. B. die Möglichkeit, Builds zu aktualisieren oder Logs zu schreiben.

Anstatt das Cloud Build-Standarddienstkonto zu verwenden, können Sie auch Ihr eigenes Dienstkonto für die Ausführung von Builds in Ihrem Namen angeben. Sie können eine beliebige Anzahl von Dienstkonten pro Projekt angeben. Durch das Verwalten mehrerer Dienstkonten können Sie diesen Dienstkonten abhängig von den ausgeführten Aufgaben unterschiedliche Berechtigungen gewähren. Sie können beispielsweise ein Dienstkonto zum Erstellen und Übertragen von Images an die Container Registry und ein anderes Dienstkonto zum Erstellen und Übertragen von Images an Artifact Registry verwenden.

Hinweis

  • Cloud Build and IAM APIs aktivieren.

    Aktivieren Sie die APIs

  • Installieren und konfigurieren Sie die Google Cloud CLI, um die Befehlszeilenbeispiele in dieser Anleitung zu verwenden.

  • Achten Sie darauf, dass Sie das Dienstkonto erstellt haben, das Sie verwenden möchten. Sie müssen das Konto in demselben Cloud-Projekt erstellen, in dem Sie Builds ausführen.

Projektübergreifende Einrichtung

Wenn sich das benutzerdefinierte Dienstkonto in einem anderen Projekt befindet als dem, in dem Sie Builds starten, gewähren Sie den erforderlichen Zugriff:

  • Achten Sie darauf, dass in dem Projekt mit dem benutzerdefinierten Dienstkonto die Einschränkung der Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage nicht erzwungen wird. Diese Einschränkung wird standardmäßig erzwungen. Führen Sie den folgenden Befehl aus, um diese Einschränkung der Organisationsrichtlinie zu deaktivieren. Dabei ist SERVICE_ACCOUNT_PROJECT_ID das Projekt, das Ihr benutzerdefiniertes Dienstkonto enthält:

       gcloud resource-manager org-policies disable-enforce \
          iam.disableCrossProjectServiceAccountUsage \
          --project=SERVICE_ACCOUNT_PROJECT_ID
    
  • Weisen Sie dem Cloud Build-Dienst-Agent des Projekts, in dem Sie Builds ausführen, die Rolle roles/iam.serviceAccountTokenCreator zu, die das benutzerdefinierte Dienstkonto enthält:

       gcloud projects add-iam-policy-binding SERVICE_ACCOUNT_PROJECT_ID \
           --member="serviceAccount:BUILD_SERVICE_AGENT \
           --role="roles/iam.serviceAccountTokenCreator"
    

    Ersetzen Sie die Platzhalterwerte im obigen Befehl durch Folgendes:

    • SERVICE_ACCOUNT_PROJECT_ID: Die Projekt-ID des Projekts, das Ihr benutzerdefiniertes Dienstkonto enthält.
    • BUILD_SERVICE_AGENT: Die E-Mail-ID des Dienst-Agents im Format service-BUILD_PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com, wobei BUILD_PROJECT_NUMBER die Projektnummer des Projekts ist, in dem Sie Builds ausführen. Sie finden die Projektnummer auf der Seite Projekteinstellungen.

Beschränkungen:

  • Ihr Cloud-Projekt muss sich in einer Google Cloud-Organisation befinden.
  • Sie müssen Builds in der Befehlszeile mit gcloud builds submit oder gcloud beta builds triggers create starten. Damit Sie die Trigger-Seite in der Google Cloud Console verwenden können, müssen sich das benutzerdefinierte Dienstkonto und der Build-Trigger im selben Projekt befinden.

Build-Logs einrichten

Wenn Sie ein eigenes Dienstkonto für Builds angeben möchten, müssen Sie Ihre Build-Logs entweder in Cloud Logging oder in einem vom Nutzer erstellten Cloud Storage-Bucket speichern. Sie können Ihre Logs nicht im Standard-Log-Bucket speichern.

Erforderliche IAM-Berechtigungen

  • Zum Starten von Builds mit dem benutzerdefinierten Dienstkonto benötigt der Nutzer, der den Build anfordert, in dem Projekt mit dem Dienstkonto die IAM-Rolle Dienstkontonutzer (roles/iam.serviceAccountUser).

  • Gewähren Sie dem Dienstkonto die Rolle Logautor (roles/logging.logWriter), um Build-Logs in Logging zu speichern.

  • Wenn Sie erstellte Images oder Artefakte in Artifact Registry, Container Registry oder Cloud Storage speichern, gewähren Sie den erforderlichen Zugriff:

  • Erteilen Sie alle anderen IAM-Berechtigungen, die das Dienstkonto zum Ausführen des Builds benötigt. Wenn Ihr Build beispielsweise auf App Engine bereitgestellt werden muss, benötigt das Dienstkonto die Rolle „App Engine-Administrator“, oder wenn Ihr Build Quellen aus einem Cloud Storage-Bucket angibt, benötigt das Dienstkonto die Rolle "Storage-Administrator".

Eine Anleitung zum Zuweisen von IAM-Rollen zu einem Dienstkonto finden Sie unter Zugriff auf Ressourcen konfigurieren.

Builds über die Befehlszeile ausführen

  1. Erstellen Sie im Stammverzeichnis des Projekts die Build-Konfigurationsdatei cloudbuild.yaml oder cloudbuild.json für Cloud Build.

  2. In der Build-Konfigurationsdatei:

    • Fügen Sie das Feld serviceAccount hinzu, das die E-Mail-Adresse Ihres Dienstkontos angibt.
    • Wenn Sie die Build-Logs in Logging speichern, fügen Sie das Feld logging hinzu und setzen Sie den Wert des Felds auf CLOUD_LOGGING_ONLY.
    • Wenn Sie die Build-Logs in einem von Nutzern erstellten Cloud Storage-Bucket speichern:
      • Fügen Sie das Feld logging hinzu und legen Sie als Wert GCS_ONLY fest.
      • Fügen Sie das Feld logsBucket hinzu und legen Sie als Wert den Standort Ihres Cloud Storage-Buckets fest.

    Sie können keine Logs im Standard-Log-Bucket speichern, wenn Sie das benutzerdefinierte Dienstkonto verwenden.

    Mit der folgenden Build-Konfigurationsdatei wird Cloud Build so konfiguriert, dass Builds mit einem benutzerdefinierten Dienstkonto ausgeführt werden. Außerdem werden Build-Logs konfiguriert, die in einem vom Nutzer erstellten Cloud Storage-Bucket gespeichert werden sollen:

    YAML

    steps:
    - name: 'bash'
      args: ['echo', 'Hello world!']
    logsBucket: 'LOGS_BUCKET_LOCATION'
    serviceAccount: 'projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT'
    options:
      logging: GCS_ONLY
    

    JSON

    {
      "steps": [
      {
        "name": "bash",
        "args": [
          "echo",
          "Hello world!"
        ]
      }
      ],
      "logsBucket": "LOGS_BUCKET_LOCATION",
      "serviceAccount": "projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT",
      "options": {
        "logging": "GCS_ONLY"
      }
    }
    

    Ersetzen Sie die Platzhalterwerte in Ihrer Build-Konfigurationsdatei durch Folgendes:

    • LOGS_BUCKET_LOCATION ist der Cloud Storage-Bucket, in dem Build-Logs gespeichert werden. Beispiel: gs://mylogsbucket.
    • PROJECT_ID ist die ID des Cloud-Projekts, in dem Sie den Build ausführen.
    • SERVICE_ACCOUNT ist die E-Mail-Adresse oder eindeutige ID des Dienstkontos, das Sie für Builds angeben möchten. Die E-Mail-Adresse eines Dienstkontos sieht beispielsweise so aus: service-account-name@project-id.iam.gserviceaccount.com.

    In diesem Beispiel hat das Feld serviceAccount den Wert projects/project-id/serviceAccounts/service-account-name@project-id.iam.gserviceaccount.com.

  3. Starten Sie mit der Build-Konfigurationsdatei den Build:

     gcloud builds submit --config CONFIG_FILE_PATH SOURCE_DIRECTORY
    

Ersetzen Sie die Platzhalterwerte in den obigen Befehlen durch Folgendes:

  • CONFIG_FILE_PATH ist der Pfad zur Build-Konfigurationsdatei.
  • SOURCE_DIRECTORY ist der Pfad oder die URL zum Quellcode.

Wenn Sie CONFIG_FILE_PATH und SOURCE_DIRECTORY im Befehl gcloud builds submit nicht angeben, geht Cloud Build davon aus, dass sich die Build-Konfigurationsdatei und der Quellcode im aktuellen Arbeitsverzeichnis befinden.

Builds mit Build-Triggern ausführen

  1. Erstellen Sie in Ihrem Quell-Repository eine Build-Konfigurationsdatei namens cloudbuild.yaml oder cloudbuild.json für Cloud Build.

  2. In der Build-Konfigurationsdatei:

    • Wenn Sie die Build-Logs in Logging speichern, fügen Sie das Feld logging hinzu und setzen Sie den Wert des Felds auf CLOUD_LOGGING_ONLY.
    • Wenn Sie die Build-Logs in einem von Nutzern erstellten Cloud Storage-Bucket speichern:
      • Fügen Sie das Feld logging hinzu und legen Sie als Wert GCS_ONLY fest.
      • Fügen Sie das Feld logsBucket hinzu und legen Sie als Wert den Standort Ihres Cloud Storage-Buckets fest.

    Sie können keine Logs im Standard-Log-Bucket speichern, wenn Sie das benutzerdefinierte Dienstkonto verwenden.

    Die folgende Build-Konfigurationsdatei konfiguriert Build-Logs, die in einem vom Nutzer erstellten Cloud Storage-Bucket gespeichert werden:

    YAML

    steps:
    - name: 'bash'
      args: ['echo', 'Hello world!']
    logsBucket: 'LOGS_BUCKET_LOCATION'
    options:
      logging: GCS_ONLY
    

    JSON

    {
      "steps": [
      {
        "name": "bash",
        "args": [
          "echo",
          "Hello world!"
        ]
      }
      ],
      "logsBucket": "LOGS_BUCKET_LOCATION",
      "options": {
        "logging": "GCS_ONLY"
      }
    }
    

    Ersetzen Sie den Platzhalterwert in Ihrer Build-Konfigurationsdatei durch Folgendes:

    • LOGS_BUCKET_LOCATION ist der Cloud Storage-Bucket, in dem Build-Logs gespeichert werden. Beispiel: gs://mylogsbucket.
  3. Geben Sie ein Dienstkonto an, das mit Ihrem Build-Trigger verwendet werden soll:

    Console

    Damit Builds über die Trigger-UI in der Google Cloud Console ausgeführt werden können, muss sich das benutzerdefinierte Dienstkonto im selben Projekt wie der Build-Trigger befinden. Wenn Sie Trigger mit projektübergreifenden Dienstkonten verwenden möchten, erstellen Sie den Build-Trigger mit dem gcloud-Tool.

    1. Build-Trigger erstellen oder bearbeiten
    2. Geben Sie im Feld Dienstkonto Ihr Dienstkonto an. Wenn Sie kein Dienstkonto angeben, wird das Standard-Cloud Build-Dienstkonto verwendet.
    3. Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

    gcloud

    Geben Sie beim Erstellen eines Build-Triggers Ihr Dienstkonto mit dem Flag --service-account an. Wenn Sie kein Dienstkonto angeben, wird das Cloud Build-Standarddienstkonto verwendet. Im folgenden Beispiel erstellt der Befehl gcloud einen Build-Trigger, wenn sich der Quellcode in GitHub befindet:

     gcloud beta builds triggers create github \
        --name=TRIGGER_NAME \
        --repo-name=REPO_NAME \
        --repo-owner=REPO_OWNER \
        --branch-pattern=BRANCH_PATTERN
        --build-config=BUILD_CONFIG_FILE
        --service-account=SERVICE_ACCOUNT
        --project=BUILD_PROJECT
    

    Ersetzen Sie die Platzhalterwerte in Ihrer Build-Konfigurationsdatei durch Folgendes:

    • TRIGGER_NAME ist der Name Ihres Build-Triggers.
    • REPO_NAME ist der Name Ihres Repositorys.
    • REPO_OWNER ist der Nutzername des Repository-Inhabers.
    • BRANCH_PATTERN ist der Zweigname in Ihrem Repository, für den der Build aufgerufen werden soll.
    • TAG_PATTERN ist der Tag-Name in Ihrem Repository, in dem der Build ausgelöst werden soll.
    • BUILD_CONFIG_FILE ist der Pfad zu Ihrer Build-Konfigurationsdatei.
    • SERVICE_ACCOUNT ist die mit Ihrem Dienstkonto verknüpfte E-Mail-Adresse.
    • BUILD_PROJECT ist das Projekt, in dem Sie Builds starten.

Der Build-Trigger löst einen Build als Reaktion auf das mit Ihrem Trigger verknüpfte Ereignis aus. Beispielsweise wird Ihr Trigger ausgeführt, wenn Quellcode in das Repository übertragen wird. Weitere Informationen zu Triggern finden Sie unter Build-Trigger erstellen und verwalten.

Nächste Schritte