Builds auf Organisationsrichtlinie abstimmen

Mit Cloud Build können Sie eine Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations) definieren, um zu steuern, welche externen Dienste Build-Trigger aufrufen können. Wenn Ihr Trigger beispielsweise auf Änderungen an einem GitHub-Repository wartet und GitHub in der Organisationsrichtlinie abgelehnt wird, wird der Trigger nicht ausgeführt. Sie können eine beliebige Anzahl zulässiger oder abgelehnter Werte für Ihre Organisation oder Ihr Projekt angeben.

Auf dieser Seite wird erläutert, wie Sie die Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations) für Integrationen mit der Google Cloud Console und dem gcloud Befehlszeilentool einrichten.

Vorbereitung

  • Aktivieren Sie die Cloud Build und Organization Policy APIs.

    Erforderliche Rollen zum Aktivieren von APIs

    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

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

  • Zum Festlegen, Ändern oder Löschen von Organisationsrichtlinien müssen Sie die Rolle „Administrator für Unternehmensrichtlinien“ (roles/orgpolicy.policyAdmin) haben. Informationen zum Hinzufügen der Rolle zu Ihrem Konto finden Sie unter Organisationsrichtlinienadministrator hinzufügen.

Organisationsrichtlinie für zulässige Integrationen einrichten

In diesem Abschnitt wird erläutert, wie Sie die Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations) einrichten können, um Builds für zulässige Integrationen zu definieren.

Console

  1. Öffnen Sie in der Google Cloud Console die Seite Organisationsrichtlinien.

    Öffnen Sie die Seite Organisationsrichtlinien.

  2. Klicken Sie auf die Zeile mit der Richtlinie Zulässige Integrationen (Cloud Build).

    Die Seite Richtliniendetails wird angezeigt.

  3. Klicken Sie auf Bearbeiten, um die Richtlinie zu bearbeiten.

    Die Seite Richtlinie bearbeiten wird angezeigt.

  4. Wählen Sie im Abschnitt Gilt für die Option Anpassen aus, um die Definition für Ihre Richtlinie festzulegen.

  5. Wählen Sie im Abschnitt Richtlinienerzwingung die Option Ersetzen aus, um eigene Regeln für die Richtlinie zu definieren. Wählen Sie andernfalls Mit übergeordneter Ressource zusammenführen aus, damit die Regeln der übergeordneten Ressource auf Ihre Einstellungen angewendet werden. Weitere Informationen finden Sie unter Informationen zu Evaluierungen der Hierarchie.

  6. Klicken Sie im Abschnitt Regeln auf Regel hinzufügen, um eine neue Regel für Ihre Richtlinie hinzuzufügen.

  7. Wählen Sie unter Richtlinienwerte die Option Alle zulassen aus, um Builds von allen Diensten zuzulassen, Alle ablehnen , um Builds von allen Diensten abzulehnen, oder Benutzerdefiniert , um Builds von bestimmten Diensten zuzulassen oder abzulehnen.

    Wenn Sie Benutzerdefiniert als Wert auswählen, führen Sie die folgenden Schritte aus:

    1. Wählen Sie im Abschnitt Richtlinientyp die Option Zulassen oder Ablehnen aus.

    2. Geben Sie im Abschnitt Benutzerdefinierte Werte die Host-URL der Instanz oder des Repository ein, für die bzw. das Sie Builds zulassen oder ablehnen möchten. Wenn Sie beispielsweise Builds von GitHub zulassen oder ablehnen möchten, geben Sie Ihre URL als github.com oder www.github.com ein.

      Sie können auch mehrere URLs eingeben, die durch ein Leerzeichen getrennt sind. Beispiel: github.com ghe.staging-test.com.

      Je nach Ereignis ist die von Ihnen angegebene Host-URL eine der folgenden:

      • RepoSync-Ereignis: Der Host ist source.developers.google.com.
      • GitHub-App-Ereignis: Der Host wird aus dem Feld repository.html_url in Ihrer JSON-Nutzlast abgeleitet, das immer github.com ist.
      • GitHub Enterprise-Ereignis: Der Host wird aus dem Feld repository.html_url in Ihrer JSON-Nutzlast abgeleitet. Beispiel: ghe.staging-test.com.
      • Pub/Sub-Ereignis: Der Host wird aus der im Trigger angegebenen Quelle abgeleitet. Wenn in Ihrem Trigger keine Quelle angegeben ist, erfolgt keine Überprüfung der Organisationsrichtlinie.
      • Webhook-Ereignis: Der Host wird aus der im Trigger angegebenen Quelle abgeleitet. Wenn in Ihrem Trigger keine Quelle angegeben ist, erfolgt eine Überprüfung der Organisationsrichtlinie.

  8. Klicken Sie auf Fertig, um die Regel zu speichern.

  9. Klicken Sie auf Regel hinzufügen, um eine weitere Regel hinzuzufügen. Klicken Sie andernfalls auf Speichern , um die Richtlinie zu speichern.

gcloud

  1. Öffnen Sie ein Terminalfenster.

  2. Wenn Sie Builds von allen Diensten zulassen oder ablehnen möchten, erstellen Sie eine YAML-Datei mit dem folgenden Inhalt:

    name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
spec:
  inheritFromParent: INHERIT
  rules:
    - ALLOW_OR_DENY: true

    Wobei:

    • PROJECT_NUMBER Ihre Projektnummer ist.
    • INHERIT true ist, wenn die Richtlinienregeln von der übergeordneten Ressource übernommen werden sollen. Andernfalls false.
    • ALLOW_OR_DENY allowAll ist, wenn Sie Builds von allen Host-URLs zulassen möchten. Andernfalls denyAll.
    • HOST_URL Ihre Host-URL ist. Beispiel: github.com. Sie können in den folgenden Zeilen auch zusätzliche URLs angeben.

    Wenn Sie Builds von ausgewählten Diensten zulassen oder ablehnen möchten, erstellen Sie eine YAML-Datei mit dem folgenden Inhalt:

    name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
spec:
  inheritFromParent: INHERIT
  rules:
    - values:
        ALLOW_OR_DENY:
          HOST_URL
          ...

    Wobei:

    • PROJECT_NUMBER Ihre Projektnummer ist.
    • INHERIT true ist, wenn die Richtlinienregeln von der übergeordneten Ressource übernommen werden sollen. Andernfalls false.
    • ALLOW_OR_DENY allowedValues ist, wenn Sie Host-URLs angeben möchten, von denen Builds zugelassen werden sollen. Andernfalls deniedValues.
    • HOST_URL Ihre Host-URL ist. Beispiel: github.com. Sie können in den folgenden Zeilen auch zusätzliche URLs angeben.

  3. Legen Sie die Organisationsrichtlinie fest, indem Sie den folgenden Befehl ausführen. Dabei ist FILE_NAME der Name Ihrer YAML-Datei:

     gcloud org-policies set-policy FILE_NAME

  4. Führen Sie den folgenden Befehl aus, um zu bestätigen, dass die Richtlinie festgelegt wurde, wobei PROJECT_ID Ihre Projekt-ID ist:

     gcloud org-policies describe cloudbuild.allowedIntegrations --effective --project PROJECT_ID

Organisationsrichtlinie für zulässige Integrationen testen

In diesem Abschnitt wird erläutert, wie Sie die Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations) mit Build-Triggern testen können.

  1. Erstellen Sie einen Build-Trigger, falls noch nicht geschehen.

  2. Übertragen Sie eine Änderung per Push an Ihre Quelle.

  3. Wenn Ihre Richtlinie so eingerichtet ist, dass Builds aus Ihrer Quelle zugelassen werden, können Sie die Build-Ausführungen aus Ihrem Trigger auf der Seite **Build-Verlauf** ansehen. Andernfalls wird der Build nicht ausgeführt. Wenn Sie den Verlauf von Builds aufrufen möchten, die durch Ihre Richtliniendefinition eingeschränkt sind, sehen Sie auf der Seite Log-Explorer nach dem Grund für die JSON-Nutzlast und dem Grund für die Ablehnung.

Nächste Schritte