Builds auf der Organisationsrichtlinie beschränken

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 von zulässigen oder abgelehnten Werten 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 können.

Vorbereitung

Cloud Build and Organization Policy APIs aktivieren.
Aktivieren Sie die APIs
Wenn Sie die Befehlszeilenbeispiele in dieser Anleitung verwenden möchten, installieren und konfigurieren Sie das Google Cloud SDK.

Hinweis: Wenn Sie das Google Cloud SDK bereits installiert haben, prüfen Sie, ob Sie die neueste verfügbare Version haben. Führen Sie dazu gcloud components update aus.
Zum Festlegen, Ändern oder Löschen einer Organisationsrichtlinie benötigen Sie die Rolle „Organization Policy Administrator“ (roles/orgpolicy.policyAdmin). 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

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

Zur Seite „Organisationsrichtlinien“
Klicken Sie auf die Zeile mit der Richtlinie Allowed Integrations (Cloud Build) (Zulässige Integrationen (Cloud Build)).

Die Seite Richtliniendetails wird angezeigt.
Klicken Sie zum Bearbeiten der Richtlinie auf Bearbeiten.

Die Seite Richtlinie bearbeiten wird angezeigt.
Wählen Sie im Abschnitt Gilt für die Option Anpassen aus, um die Definition für Ihre Richtlinie festzulegen.
Wählen Sie im Abschnitt Richtlinienerzwingung die Option Ersetzen aus, um Ihre eigenen 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.
Klicken Sie im Abschnitt Regeln auf Regel hinzufügen, um eine neue Regel für Ihre Richtlinie hinzuzufügen.
Wählen Sie unter Richtlinienwerte die Option Alle zulassen aus, um Builds aller Dienste zuzulassen. Wählen Sie Alle ablehnen aus, um Builds von allen Diensten abzulehnen, oder Benutzerdefiniert, um Builds von bestimmten Diensten zuzulassen oder abzulehnen.

Wenn Sie als Wert Benutzerdefiniert 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 Bereich Benutzerdefinierte Werte die Host-URL der Instanz oder des Repositorys ein, für das Sie Builds zulassen oder ablehnen möchten. Wenn Sie beispielsweise Builds von GitHub zulassen oder ablehnen möchten, geben Sie die 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-Anwendungsereignis: Der Host wird aus dem Feld repository.html_url in Ihrer JSON-Nutzlast abgeleitet, die 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 im Trigger keine Quelle angegeben ist, wird keine Organisationsrichtlinienprüfung durchgeführt.
  - Webhook-Ereignis: Der Host wird aus der im Trigger angegebenen Quelle abgeleitet. Wenn im Trigger keine Quelle angegeben ist, wird eine Organisationsrichtlinienprüfung durchgeführt.
  Hinweis: Sie können im Abschnitt Benutzerdefinierte Werte beliebige Zeichen eingeben, mit Ausnahme von Doppelpunkten (:) und Schrägstrichen (/).
Klicken Sie auf Fertig, um die Regel zu speichern.
Um eine weitere Regel hinzuzufügen, klicken Sie auf Regel hinzufügen. Klicken Sie andernfalls auf Speichern, um die Richtlinie zu speichern.

gcloud

Öffnen Sie ein Terminalfenster.
Wenn Sie Builds von allen Diensten zulassen oder ablehnen möchten, erstellen Sie eine YAML-Datei mit folgendem Inhalt:
```
name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
spec:
  inheritFromParent: INHERIT
  rules:
    - ALLOW_OR_DENY: true
```
Wobei:
- PROJECT_NUMBER ist Ihre Projektnummer.
- INHERIT ist true, wenn Sie möchten, dass die Richtlinienregeln von der übergeordneten Ressource übernommen werden. Andernfalls false.
- ALLOW_OR_DENY ist allowAll, wenn Sie Builds von allen Host-URLs zulassen möchten. Andernfalls denyAll.
- HOST_URL ist Ihre Host-URL. 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 folgendem Inhalt:
```
name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
spec:
  inheritFromParent: INHERIT
  rules:
    - values:
        ALLOW_OR_DENY:
          HOST_URL
          ...
```
Wobei:
- PROJECT_NUMBER ist Ihre Projektnummer.
- INHERIT ist true, wenn Sie möchten, dass die Richtlinienregeln von der übergeordneten Ressource übernommen werden. Andernfalls false.
- ALLOW_OR_DENY ist allowedValues, wenn Sie Host-URLs angeben möchten, von denen Builds zugelassen werden sollen. Andernfalls deniedValues.
- HOST_URL ist Ihre Host-URL. Beispiel: github.com Sie können in den folgenden Zeilen auch zusätzliche URLs angeben.
Hinweis: Sie können bei der Angabe der Host-URL beliebige Zeichen verwenden, mit Ausnahme von Doppelpunkten (:) und Schrägstrichen (/).
Legen Sie Ihre Organisationsrichtlinie fest. Führen Sie dazu den folgenden Befehl aus, wobei FILE_NAME der Name der YAML-Datei ist:
```
 gcloud org-policies set-policy FILE_NAME
```
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 Ihre Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations) mit Build-Triggern testen können.

Erstellen Sie einen Build-Trigger, falls noch nicht geschehen.
Übertragen Sie eine Änderung per Push an die Quelle.
Wenn Ihre Richtlinie so eingerichtet ist, dass Builds von Ihrer Quelle zugelassen werden, können Sie Build-Ausführungen aus Ihrem Trigger auf der Seite Build-Verlauf ansehen. Andernfalls wird der Build nicht ausgeführt. Wenn Sie sich den Verlauf von Builds ansehen möchten, die durch Ihre Richtliniendefinition eingeschränkt sind, finden Sie auf der Seite Log-Explorer den Grund für die JSON-Nutzlast und den Grund für die Ablehnung.

Nächste Schritte

Build-Trigger erstellen und verwalten
Builds mit Genehmigung steuern
Weitere Informationen zu den Berechtigungen zum Aufrufen von Build-Logs
Informationen zu Audit-Logs, die von Cloud Build erstellt wurden