Benutzerdefinierte Dienstkonten konfigurieren

Um in Cloud Build dem Grundsatz der geringsten Berechtigung zu folgen, können Sie Cloud Build so konfigurieren, dass ein Dienstkonto mit nur ausreichenden Berechtigungen zum Ausführen eines Builds verwendet wird. Auf dieser Seite wird beschrieben, wie Sie ein Dienstkonto einrichten.

Wenn Sie kein Dienstkonto angeben, wählt Cloud Build möglicherweise automatisch ein Dienstkonto aus, um Builds in Ihrem Namen auszuführen. Dieses Dienstkonto hat möglicherweise Berechtigungen, die für Ihren Anwendungsfall unnötig weit gefasst sind, z. B. Zugriff auf Ihre Cloud Source Repositories und alle Cloud Storage-Bucket in Ihrem Projekt.

Um die Sicherheit Ihrer Projekte zu verbessern und die potenziellen Auswirkungen von Fehlkonfigurationen oder böswilligen Nutzern zu verringern, empfehlen wir, das Prinzip der geringsten Berechtigung zu befolgen. Wenn Sie diesen Grundsatz anwenden, können Sie jedem Dienstkonto die Berechtigungen und Rollen zuweisen, die für die jeweilige Aufgabe erforderlich sind. Sie können beispielsweise ein Dienstkonto zum Erstellen und Übertragen von Images an Artifact Registry verwenden, wie im Google Cloud Blog gezeigt.

Hinweise

• Enable the Cloud Build and IAM APIs.

  Enable the 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.

  Enable the API

• Erstellen Sie ein Dienstkonto, falls Sie noch keines haben.

IAM-Berechtigungen gewähren

Damit Ihr Build auf die Dienste zugreifen kann, mit denen eine Verbindung hergestellt werden 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

   Der Tab Dienstkontoberechtigungen wird 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 gewünschten Rolle auf Aktivieren.

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

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

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 Protokolle nicht im Standard-Log-Bucket speichern.

• Folgen Sie der Anleitung unter Build-Logs im vom Nutzer erstellten Bucket speichern, um Ihre Logs in einem Cloud Storage-Bucket zu speichern. Achten Sie darauf, keine Aufbewahrungsrichtlinie für den Log-Bucket festgelegt zu haben, da dies dazu führen kann, dass Cloud Build keine Build-Logs in den Bucket schreibt.

• Wenn Sie Build-Logs in Cloud Logging speichern möchten, weisen Sie dem Dienstkonto die Rolle Logautor (roles/logging.logWriter) zu.

• Weitere Informationen zum Speicherort 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 manuell mit einer Konfigurationsdatei 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 bevorzugte 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 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 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 die gewünschte Protokollierungsoption 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, in dem Build-Logs gespeichert werden sollen. 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 -Konsole 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 wird mit dem Befehl gcloud ein Build-Trigger erstellt, 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 Ihr Dienstkonto im Format /projects/PROJECT_ID/serviceAccounts/ACCOUNT_ID_OR_EMAIL.
   • BUILD_PROJECT ist das Projekt, in dem Sie Builds starten.

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

Projektübergreifende Einrichtung

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

• Achten Sie darauf, dass die Einschränkung der Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage im Projekt mit dem von Ihnen angegebenen Dienstkonto 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 steht SERVICE_ACCOUNT_PROJECT_ID für das Projekt, das das von Ihnen angegebene Dienstkonto enthält:

  gcloud resource-manager org-policies disable-enforce \
     iam.disableCrossProjectServiceAccountUsage \
     --project=SERVICE_ACCOUNT_PROJECT_ID
  

• Weisen Sie in dem Projekt, in dem sich das von Ihnen angegebene Dienstkonto befindet, dem Cloud Build-Dienst-Agent des Projekts, in dem Sie Builds ausführen, 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 Kundenservicemitarbeiters 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.

• Sie müssen Builds in der Befehlszeile mit gcloud builds submit oder gcloud builds triggers create starten. 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 in Cloud Build
• Weitere Informationen zu den Änderungen an Dienstkonten