Benutzerdefinierte Dienstkonten konfigurieren

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

Cloud Build verwendet standardmäßig ein spezielles Dienstkonto, um Builds für Sie auszuführen. 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, zum Beispiel die Möglichkeit, Builds zu aktualisieren oder Logs zu schreiben.

Anstatt das Cloud Build-Standarddienstkonto zu verwenden, können Sie Ihr eigenes Dienstkonto angeben, um Builds für Sie auszuführen. Sie können eine beliebige Anzahl von Dienstkonten pro Projekt angeben. Das Verwalten mehrerer Dienstkonten ermöglicht es Ihnen, diesen Dienstkonten abhängig von den Aufgaben, die sie ausführen, unterschiedliche Berechtigungen zu gewähren. Sie können beispielsweise ein Dienstkonto zum Erstellen und Übertragen von Images in Container Registry und ein anderes Dienstkonto zum Erstellen und Übertragen von Images in Artifact Registry verwenden.

Hinweis

  • Cloud Build and IAM APIs aktivieren.

    Aktivieren Sie die APIs

  • Um die Befehlszeilenbeispiele in dieser Anleitung zu verwenden, installieren und konfigurieren Sie das Cloud SDK.

  • Prüfen Sie, ob Sie das Dienstkonto erstellt haben, das Sie verwenden möchten. Sie müssen das Konto in dem Cloud-Projekt erstellen, in dem Sie Builds ausführen.

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 Ihrem eigenen Cloud Storage-Bucket speichern:

Erforderliche IAM-Berechtigungen

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 für Cloud Build mit dem Namen cloudbuild.yaml oder cloudbuild.json.

  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 Ihrem Cloud Storage-Bucket speichern, fügen Sie ein Feld logsBucket hinzu, das auf Ihren Cloud Storage-Bucket verweist.

    YAML

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

    JSON

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

    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_NAME ist der Name 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. Beispiel: my-sa-name@my-project-name.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 die Cloud Build-Build-Konfigurationsdatei mit dem Namen cloudbuild.yaml oder cloudbuild.json.

  2. Konfigurieren Sie Ihren Build zum Speichern von Logs in Logging oder in einem vom Nutzer erstellten Cloud Storage-Bucket. Der Standard-Bucket kann nicht verwendet werden, wenn Sie ein benutzerdefiniertes Dienstkonto verwenden möchten. Im folgenden Beispiel verweist das Feld logsBucket auf einen Cloud Storage-Bucket:

    YAML

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

    JSON

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

    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

    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 das Dienstkonto mit dem Flag --service-account an. Wenn Sie kein Dienstkonto angeben, wird das Standard-Cloud Build-Dienstkonto 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
    

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

    • TRIGGER_NAME ist der Name des Build-Triggers.
    • REPO_NAME ist der Name Ihres Repositorys.
    • REPO_OWNER ist der Nutzername des Repository-Inhabers.
    • BRANCH_PATTERN ist der Branch-Name in Ihrem Repository zum Aufrufen des Builds.
    • TAG_PATTERN ist der Tag-Name in Ihrem Repository, in dem der Build aufgerufen werden soll.
    • BUILD_CONFIG_FILE ist der Pfad zu Ihrer Build-Konfigurationsdatei.
    • SERVICE_ACCOUNT ist die mit Ihrem Dienstkonto verknüpfte E-Mail-Adresse.

Der Build-Trigger ruft einen Build als Reaktion auf das mit dem Trigger verknüpfte Ereignis auf. Der Trigger wird beispielsweise ausgeführt, wenn Quellcode per Push in das Repository übertragen wird. Weitere Informationen zu Triggern finden Sie unter Build-Trigger erstellen und verwalten.

Nächste Schritte