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 dokumentiert, um ein Dienstkonto einzurichten.

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

Um den Sicherheitsstatus Ihrer Projekte zu verbessern und die potenziellen Auswirkungen zu reduzieren von Fehlkonfigurationen oder schädlichen Nutzern, empfehlen wir, das Prinzip der die geringste Berechtigung haben. Entsprechend diesem Prinzip können Sie jedem Dienstkonto die Berechtigungen und Rollen für die auszuführende Aufgabe. So können Sie zum Beispiel Ein Dienstkonto zum Erstellen und Übertragen von Images in Artifact Registry verwenden (siehe Abbildung) im Google Cloud-Blog.

Hinweise

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

    Sie sehen den Tab Dienstkontoberechtigungen:

    Screenshot der Seite "Dienstkontoberechtigungen"

  2. Wählen Sie aus der Drop-down-Liste das Dienstkonto aus, dessen Rollen Sie ändern können.

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

  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“.

Hier finden Sie weitere Informationen zu den Rollen, die häufig für eine auf Zugriff auf Cloud Build konfigurieren Ressourcen und in der vollständigen Liste der Cloud Build-IAM-Ressourcen Rollen und Berechtigungen.

Build-Logs einrichten

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

Build mit einer Konfigurationsdatei ausführen

So führen Sie einen Build manuell mithilfe 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 einen logging und legen 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. wo 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: Ein Dienst Konto-E-Mail-Adresse sieht wie folgt aus: 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 Triggern ausführen

So führen Sie einen Build mit Cloud Build-Triggern aus: Dienstkonto erstellen, richten Sie Ihre bevorzugte Logging-Option ein und wählen Sie bevorzugtes Dienstkonto beim Erstellen des Triggers.

  1. In der Build-Konfigurationsdatei:

    • Wenn Sie die Build-Logs in Cloud Logging speichern, fügen Sie einen logging und legen Sie den Wert des Felds auf CLOUD_LOGGING_ONLY fest.

    • 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 zum Speichern konfiguriert in einem nutzererstellten Cloud Storage-Bucket:

    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

    Zum Ausführen von Builds über die Seite „Trigger“ in der Google Cloud Console Das benutzerdefinierte Dienstkonto muss sich im selben Projekt wie Ihr Build befinden auslösen. Um Trigger mit projektübergreifenden Dienstkonten zu verwenden, erstellen Sie den Build-Trigger mit dem gcloud-Tool erstellen.

    1. Build-Trigger erstellen oder bearbeiten

    2. Geben Sie im Feld Dienstkonto Ihr Dienstkonto an. Wenn Sie kein Dienstkonto angeben, verwendet Cloud Build die Standarddienstkonto ändern.

    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 in das Format /projects/PROJECT_ID/serviceAccounts/ACCOUNT_ID_OR_EMAIL.
    • BUILD_PROJECT ist das Projekt, in dem Sie Builds starten.

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. Zum Deaktivieren dieser Funktion Einschränkung der Organisationsrichtlinie: Führen Sie den folgenden Befehl aus, wobei SERVICE_ACCOUNT_PROJECT_ID ist das Projekt, das Ihr benutzerdefiniertes Dienstkonto enthält:

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

  • Gewähren Sie im Projekt, das Ihr benutzerdefiniertes Dienstkonto enthält, den Rolle roles/iam.serviceAccountTokenCreator für die Cloud Build-Dienst-Agent des Projekts, in dem Sie sich befinden ausgeführte Builds:

    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 das Ihr benutzerdefiniertes Dienstkonto enthält.
    • BUILD_SERVICE_AGENT: Die E-Mail-ID des Kundenservicemitarbeiters 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. Die Projektnummer finden Sie in der Seite mit 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 starten oder gcloud builds triggers create. 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