Benutzerdefinierte Dienstkonten konfigurieren

Gemäß dem Prinzip der geringsten Berechtigung in Cloud Build können Sie Cloud Build so konfigurieren, dass ein Dienstkonto verwendet wird, das gerade über die erforderlichen Berechtigungen zum Ausführen eines Builds verfügt. Auf dieser Seite wird beschrieben, wie Sie ein Dienstkonto einrichten.

Wenn Sie kein Dienstkonto angeben, kann Cloud Build automatisch ein Dienstkonto auswählen, um Builds in Ihrem Namen auszuführen. Dieses Dienstkonto kann Berechtigungen haben, die für Ihren Anwendungsfall unnötig weit gefasst sind, z. B. Zugriff auf Ihre Cloud Source Repositories und einen beliebigen Cloud Storage-Bucket in Ihrem Projekt.

Wir empfehlen, das Prinzip der geringsten Berechtigung zu befolgen, um den Sicherheitsstatus Ihrer Projekte zu verbessern und die potenziellen Auswirkungen von Fehlkonfigurationen oder böswilligen Nutzern zu reduzieren. Nach diesem Prinzip können Sie jedem Dienstkonto die Berechtigungen und Rollen für die auszuführende Aufgabe zuweisen. Sie können beispielsweise ein Dienstkonto zum Erstellen und Übertragen von Images in Artifact Registry verwenden, wie im Google Cloud-Blog gezeigt.

Hinweise

• Cloud Build and IAM APIs aktivieren.

  Aktivieren Sie die APIs

• Wenn Sie dieses Konto zum Erstellen und Verwalten von Anmeldedaten verwenden möchten, z. B. zum Erstellen kurzlebiger Anmeldedaten, aktivieren Sie die IAM Service Account Credentials API.

  Aktivieren Sie die API

• Erstellen Sie ein Dienstkonto, falls noch nicht geschehen.

IAM-Berechtigungen gewähren

Damit der Build auf die Dienste zugreifen kann, zu denen er eine Verbindung herstellen muss, müssen Sie einige Rollen und Berechtigungen gewähren:

1. Öffnen Sie die Seite mit den Cloud Build-Einstellungen:

   Zur Seite mit den Cloud Build-Einstellungen

   Daraufhin wird der Tab Dienstkontoberechtigungen angezeigt:

   

2. Wählen Sie in der Drop-down-Liste das Dienstkonto aus, dessen Rollen Sie ändern möchten.

3. Setzen Sie den Status der Rolle, die Sie hinzufügen möchten, auf Aktivieren.

4. Wenn die Rolle, die Sie für Ihre Build-Pipeline benötigen, hier nicht aufgeführt ist, können Sie zusätzliche Rollen auf der Seite „IAM-Konfigurationen“ zuweisen.

Weitere Informationen zu den Rollen, die häufig für einen Build erforderlich sind, finden Sie unter Zugriff auf Cloud Build-Ressourcen konfigurieren und in der vollständigen Liste der Cloud Build-IAM-Rollen und -Berechtigungen.

Build-Logs einrichten

Wenn Sie ein eigenes Dienstkonto für Builds angeben, 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.

• Folgen Sie der Anleitung unter Build-Logs im nutzererstellten Bucket speichern, um Ihre Logs in einem Cloud Storage-Bucket zu speichern. Achten Sie darauf, dass Sie keine Aufbewahrungsrichtlinie für den Log-Bucket festgelegt haben, da Cloud Build sonst möglicherweise keine Build-Logs in den Bucket schreiben kann.

• Weisen Sie dem Dienstkonto die Rolle „Logautor“ (roles/logging.logWriter) zu, um Build-Logs in Cloud Logging zu speichern.

• Weitere Informationen zum Speichern von Build-Logs finden Sie unter Speicherort für Build-Logs auswählen.

Build mit einer Konfigurationsdatei ausführen

So führen Sie einen Build mithilfe einer Konfigurationsdatei manuell aus:

1. Erstellen Sie im Stammverzeichnis des Projekts eine Cloud Build-Konfigurationsdatei mit dem Namen cloudbuild.yaml oder cloudbuild.json.

2. Fügen Sie das Feld serviceAccount und die gewünschte Logging-Einrichtung hinzu.

   • Wenn Sie die Build-Logs in Cloud 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 vom Nutzer 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.

   Im folgenden Beispiel wird Cloud Build so konfiguriert, dass Builds mit einem benutzerdefinierten Dienstkonto ausgeführt werden. Außerdem werden Build-Logs so konfiguriert, dass sie in einem vom Nutzer erstellten Cloud Storage-Bucket gespeichert werden:

   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 Google 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: [e-mail].

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 Triggern ausführen

Wenn Sie einen Build mit Cloud Build-Triggern mit Ihrem eigenen Dienstkonto ausführen möchten, richten Sie Ihre bevorzugte Logging-Option ein und wählen Sie beim Erstellen des Triggers Ihr bevorzugtes Dienstkonto aus.

1. In der Build-Konfigurationsdatei:

   • Wenn Sie die Build-Logs in Cloud 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 vom Nutzer 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.

   Im folgenden Beispiel werden Build-Logs so konfiguriert, dass sie 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 LOGS_BUCKET_LOCATION durch den Cloud Storage-Bucket zum Speichern von Build-Logs. Beispiel: gs://mylogsbucket

2. Geben Sie ein Dienstkonto an, das mit Ihrem Build-Trigger verwendet werden soll:

   Console

   Wenn Sie Builds über die Seite „Trigger“ in der Google Cloud Console ausführen möchten, muss sich das vom Nutzer angegebene 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, verwendet Cloud Build das Standarddienstkonto.

   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. Im folgenden Beispiel erstellt der Befehl gcloud einen Build-Trigger, der Code aus einem Git-Repository abruft:

   gcloud 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 die Builds starten.

Hinweis: Wenn Sie in Ihrer Build-Konfiguration ein Dienstkonto angeben, wird es beim Ausführen des Triggers beim Build-Aufruf ignoriert. Nur das in Ihrem Trigger angegebene Dienstkonto wird für Builds verwendet, die mit Triggern aufgerufen werden.

Projektübergreifende Einrichtung

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

• Achten Sie darauf, dass in dem Projekt mit dem vom Nutzer angegebenen Dienstkonto die Einschränkung der Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage nicht erzwungen wird. Diese Einschränkung wird standardmäßig erzwungen. Führen Sie zum Deaktivieren dieser Einschränkung der Organisationsrichtlinie den folgenden Befehl aus, wobei SERVICE_ACCOUNT_PROJECT_ID das Projekt ist, 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, im Projekt mit dem vom Nutzer angegebenen Dienstkonto die Rolle roles/iam.serviceAccountTokenCreator zu:

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

  Ersetzen Sie die Platzhalterwerte im Befehl durch Folgendes:

  • SERVICE_ACCOUNT_PROJECT_ID: Die Projekt-ID des Projekts, das das vom Nutzer angegebene Dienstkonto enthält.
  • BUILD_SERVICE_AGENT: Die E-Mail-ID des Dienst-Agents im Format [e-mail], wobei BUILD_PROJECT_NUMBER die Projektnummer des Projekts ist, in dem Sie Builds ausführen. Sie finden die Projektnummer auf der Seite mit den Projekteinstellungen.

Beschränkungen:

• Ihr Google Cloud-Projekt muss sich in einer Google Cloud-Organisation befinden.

• Builds müssen in der Befehlszeile mit gcloud builds submit oder gcloud builds triggers create gestartet werden. Damit Sie die Seite „Trigger“ in der Google Cloud Console verwenden können, müssen sich das vom Nutzer angegebene Dienstkonto und der Build-Trigger im selben Projekt befinden.

Nächste Schritte

• Weitere Informationen zu IAM-Rollen und -Berechtigungen für Cloud Build
• Hier erfahren Sie, wie sich die Änderungen am Dienstkonto auf die Ausführung Ihrer Builds auswirken.