Benutzerdefinierte Dienstkonten konfigurieren

Um in Cloud Build das Prinzip der geringsten Berechtigung zu befolgen, können Sie Cloud Build so konfigurieren, dass ein Dienst konto mit genau den Berechtigungen verwendet wird, die zum Ausführen eines Builds erforderlich sind. 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, den Grundsatz 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 beschrieben.

Hinweis

  • Aktivieren Sie die Cloud Build und IAM APIs.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Informationen zum Zuweisen von Rollen.

    APIs aktivieren

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

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Informationen zum Zuweisen von Rollen.

    API aktivieren

  • Erstellen Sie ein Dienstkonto, falls noch nicht geschehen.

IAM-Berechtigungen gewähren

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

  1. Rufen Sie in der Google Cloud Console die Cloud Build Berechtigungen Seite auf:

    Berechtigungen aufrufen

  2. Rufen Sie das Menü Dienstkonto auf und wählen Sie Ihr Dienstkonto aus.

  3. Setzen Sie den Status der Rolle oder Rollen, 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 auf der Seite mit den IAM-Konfigurationen zusätzliche Rollen gewähren.

Weitere Informationen zu den Rollen, die üblicherweise 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.

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 setzen Sie den Wert auf GCS_ONLY.
      • Fügen Sie das Feld logsBucket hinzu und legen Sie als Wert den Standort Ihres Cloud Storage-Bucket 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. Eine E-Mail-Adresse eines Dienstkontos sieht beispielsweise so 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 in den gcloud builds submit Befehlen keine Werte für CONFIG_FILE_PATH und SOURCE_DIRECTORY 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 Logging-Option ein und wählen Sie beim Erstellen des Triggers das gewünschte 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 setzen Sie den Wert auf GCS_ONLY.
      • Fügen Sie das Feld logsBucket hinzu und legen Sie als Wert den Standort Ihres Cloud Storage-Bucket fest.

    Im folgenden Beispiel 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'
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. 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 benutzerdefinierte Dienstkonto im selben Projekt wie Ihr Build Trigger befinden. Wenn Sie Trigger mit projektübergreifenden Dienstkonten verwenden möchten, erstellen Sie den Build-Trigger mit dem Tool gcloud.

    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 Tagname in Ihrem Repository, für den der Build aufgerufen 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.

Projektübergreifende Einrichtung

Sie können ein benutzerdefiniertes Dienstkonto verwenden, um Builds in einem anderen Projekt als dem Projekt auszuführen, in dem Sie das Dienstkonto erstellt haben. Dies ist jedoch nur möglich, wenn die Einschränkung der Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage nicht erzwungen wird. Diese Einschränkung wird standardmäßig erzwungen. Weitere Informationen.

  • Mit dem folgenden Befehl wird das Erzwingen dieser Einschränkung deaktiviert und der erforderliche Zugriff gewährt. Ihre Organisation muss sich der damit verbundenen Sicherheitsrisiken bewusst sein, bevor sie die Einschränkung in der Organisationsrichtlinie festlegt:

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

    In diesem Befehl ist SERVICE_ACCOUNT_PROJECT_ID das Projekt, das Ihr benutzerdefiniertes Dienstkonto enthält.

  • Gewähren Sie in dem Projekt, das Ihr benutzerdefiniertes Dienstkonto enthält, dem Cloud Build-Dienst-Agent des Projekts, in dem Sie Builds ausführen, die Rolle roles/iam.serviceAccountTokenCreator:

    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 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 mit den Projekteinstellungen.

Beschränkungen :

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

  • Sie müssen Builds über die Befehlszeile mit gcloud builds submit oder gcloud builds triggers create starten. Wenn Sie die Seite „Trigger“ in der Google Cloud Console verwenden möchten, müssen sich das benutzerdefinierte Dienstkonto und der Build-Trigger im selben Projekt befinden.

Nächste Schritte