Mit Cloud Build können Sie eine Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations
) definieren, um zu steuern, welche externen Dienste Build-Trigger auslösen können. Beispiel:
Der Trigger prüft auf Änderungen an einem GitHub-Repository und GitHub.
in der Organisationsrichtlinie abgelehnt wird, wird der Trigger nicht ausgeführt. Sie können angeben,
eine beliebige Anzahl zulässiger oder abgelehnter Werte für Ihre Organisation oder Ihr Projekt.
Auf dieser Seite wird beschrieben, wie Sie die Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations
) für Integrationen mit der Google Cloud Console und dem Befehlszeilentool gcloud
einrichten.
Vorbereitung
-
Enable the Cloud Build and Organization Policy APIs.
Wenn Sie die Befehlszeilenbeispiele in dieser Anleitung verwenden möchten, müssen Sie das Google Cloud SDK installieren und konfigurieren.
Zum Festlegen, Ändern oder Löschen einer Organisationsrichtlinie benötigen Sie die Berechtigung Rolle „Administrator für Organisationsrichtlinien“ (
roles/orgpolicy.policyAdmin
). Weitere Informationen dazu, wie Sie die Rolle Ihrem Konto hinzufügen, finden Sie unter Organisationsrichtlinienadministrator hinzufügen.
Organisationsrichtlinie für zulässige Integrationen einrichten
In diesem Abschnitt wird erläutert, wie Sie die Organisationsrichtlinie einrichten können
(constraints/cloudbuild.allowedIntegrations
) zum Definieren von Builds für
zulässigen Integrationen.
Console
Öffnen Sie in der Google Cloud Console die Seite Organisationsrichtlinien.
Klicken Sie auf die Zeile mit der Richtlinie Zulässige Integrationen (Cloud Build).
Die Seite Richtliniendetails wird angezeigt.
Klicken Sie auf Bearbeiten, um die Richtlinie zu bearbeiten.
Die Seite Richtlinie bearbeiten wird angezeigt.
Wählen Sie im Abschnitt Gilt für die Option Anpassen aus, Definition Ihrer Richtlinie.
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.
Klicken Sie im Abschnitt Regeln auf Regel hinzufügen, um eine neue Regel für Ihre Richtlinie.
Wählen Sie unter Richtlinienwerte die Option Alle zulassen aus, um Builds zuzulassen. Wählen Sie Alle ablehnen aus, um Builds für alle Dienste abzulehnen oder Benutzerdefiniert auswählen, um Builds zuzulassen oder abzulehnen bestimmten Diensten.
Wenn Sie Benutzerdefiniert als Wert auswählen, führen Sie die folgenden Schritte aus:
Wählen Sie im Abschnitt Richtlinientyp die Option Zulassen oder Ablehnen aus.
Geben Sie im Abschnitt Benutzerdefinierte Werte die Host-URL der Instanz oder des Repositorys ein, von dem aus Sie Builds zulassen oder ablehnen möchten. Wenn Sie beispielsweise Builds von GitHub zulassen oder verweigern möchten, geben Sie Ihre URL als
github.com
oderwww.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 immergithub.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 von der Quelle abgeleitet. im Trigger festgelegt ist. Wenn in Ihrem Trigger keine Quelle angegeben ist, wird keine Prüfung der Organisationsrichtlinien durchgeführt.
- Webhook-Ereignis: Der Host wird von der Quelle abgeleitet. im Trigger festgelegt ist. Wenn keine Quelle vorhanden ist im Trigger angegeben ist, wird eine Organisation Richtlinienüberprüfung.
- RepoSync-Ereignis: Der Host ist
Klicken Sie auf Fertig, um die Regel zu speichern.
Wenn Sie eine weitere Regel hinzufügen möchten, klicken Sie auf Regel hinzufügen. Andernfalls müssen Sie auf Speichern.
gcloud
Öffnen Sie ein Terminalfenster.
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
ist Ihre Projektnummer.INHERIT
isttrue
, wenn Ihre Richtlinienregeln von der übergeordneten Ressource übernommen werden sollen. Andernfallsfalse
.ALLOW_OR_DENY
istallowAll
, wenn Sie Builds von allen Host-URLs zulassen möchten. AndernfallsdenyAll
.HOST_URL
ist Ihre Host-URL. Beispiel:github.com
Sie können auch zusätzliche URLs auf folgenden Seiten angeben: Linien.
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
ist Ihre Projektnummer.INHERIT
isttrue
, wenn Ihre Richtlinienregeln von der übergeordneten Ressource übernommen werden sollen. Andernfallsfalse
.ALLOW_OR_DENY
istallowedValues
, wenn Sie Host-URLs angeben möchten, von denen Builds zugelassen werden sollen. AndernfallsdeniedValues
.HOST_URL
ist Ihre Host-URL. Beispiel:github.com
In den folgenden Zeilen können Sie auch zusätzliche URLs angeben.
Legen Sie die Organisationsrichtlinie mit dem folgenden Befehl fest, wobei FILE_NAME der Name Ihrer YAML-Datei ist:
gcloud org-policies set-policy FILE_NAME
Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Richtlinie festgelegt wurde. Dabei ist PROJECT_ID Ihre Projekt-ID:
gcloud org-policies describe cloudbuild.allowedIntegrations --effective --project PROJECT_ID
Organisationsrichtlinie für zulässige Integrationen testen
In diesem Abschnitt wird beschrieben, wie Sie Ihre Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations
) mithilfe von Build-Triggern testen können.
Erstellen Sie einen Build-Trigger, falls noch nicht geschehen.
Übertragen Sie eine Änderung per Push in die Quelle.
Wenn Ihre Richtlinie so eingerichtet ist, dass Builds aus Ihrer Quelle zulässig sind, können Sie sich auf der Seite Build-Verlauf die Buildausführungen Ihres Triggers ansehen. Andernfalls wird Ihr Build nicht ausgeführt. Bis Aufrufverlauf für Builds, die durch Ihre Richtliniendefinition eingeschränkt sind, siehe den Log-Explorer auf der Seite mit dem Grund für die JSON-Nutzlast und dem Grund für die Ablehnung.
Nächste Schritte
- Build-Trigger erstellen und verwalten
- Builds nach Genehmigung freigeben
- Weitere Informationen zu den Berechtigungen zum Aufrufen von Build-Logs
- Informationen zu Audit-Logs, die von Cloud Build erstellt wurden