Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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 nicht zulässigen Werten für Ihre Organisation oder Ihr Projekt angeben.
Auf dieser Seite wird beschrieben, wie Sie die Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations) für Integrationen mit der Google Cloud Console und dem gcloud-Befehlszeilentool einrichten.
Vorbereitung
Enable the Cloud Build and Organization Policy APIs.
Wenn Sie die Befehlszeilenbeispiele in dieser Anleitung verwenden möchten, installieren und konfigurieren Sie das Google Cloud SDK.
Zum Festlegen, Ändern oder Löschen einer Organisationsrichtlinie 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 beschrieben, wie Sie die Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations) einrichten, um Builds für zulässige Integrationen zu definieren.
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, um die Definition für Ihre Richtlinie festzulegen.
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 Regeln der übergeordneten Ressource auf Ihre Einstellungen angewendet werden. Weitere Informationen finden Sie unter Informationen zu Evaluierungen der Hierarchie.
Klicken Sie im Bereich 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 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:
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, aus dem 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 Quelle abgeleitet, die in Ihrem Trigger angegeben ist. 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, wird eine Organisationsrichtlinienprüfung durchgeführt.
Klicken Sie auf Fertig, um die Regel zu speichern.
Wenn Sie eine weitere Regel hinzufügen möchten, 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 dem folgenden Inhalt:
Organisationsrichtlinie für zulässige Integrationen testen
In diesem Abschnitt wird beschrieben, wie Sie Ihre Organisationsrichtlinie (constraints/cloudbuild.allowedIntegrations) mit Build-Triggern testen können.
Wenn Ihre Richtlinie so eingerichtet ist, dass Builds aus Ihrer Quelle zulässig sind, können Sie die Build-Ausführungen aus Ihrem Trigger auf der Seite Build-Verlauf ansehen. Andernfalls wird Ihr Build nicht ausgeführt. Wenn Sie den Verlauf für Builds aufrufen möchten, die durch Ihre Richtliniendefinition eingeschränkt sind, sehen Sie auf der Seite Logs Explorer nach dem Grund für die JSON-Nutzlast und dem Ablehnungsgrund.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-01 (UTC)."],[[["\u003cp\u003eCloud Build uses an organization policy (\u003ccode\u003econstraints/cloudbuild.allowedIntegrations\u003c/code\u003e) to manage which external services can trigger builds.\u003c/p\u003e\n"],["\u003cp\u003eYou can allow or deny builds from specific services or all services by setting custom values within the organization policy using the Google Cloud console or the \u003ccode\u003egcloud\u003c/code\u003e command-line tool.\u003c/p\u003e\n"],["\u003cp\u003eWhen configuring the policy, you can choose to merge settings with a parent policy or replace them entirely, using the console, as well as to inherit from the parent via gcloud.\u003c/p\u003e\n"],["\u003cp\u003eThe host URL for events varies based on the source, such as \u003ccode\u003egithub.com\u003c/code\u003e for GitHub app events, or the source specified in your trigger for Pub/Sub and Webhook events.\u003c/p\u003e\n"],["\u003cp\u003eYou can test the configured organization policy by creating a build trigger and pushing a change, checking the Build history page to see if the build executed, and view the logs for rejected builds.\u003c/p\u003e\n"]]],[],null,["Cloud Build enables you to define an organization policy\n(`constraints/cloudbuild.allowedIntegrations`) to control\nwhich external services can invoke build triggers. For example,\nif your trigger listens for changes to a GitHub repository and GitHub\nis denied in the organization policy, your trigger will not run. You can specify\nany number of allowed or denied values for your organization or project.\n\nThis page explains how you can set up the organization policy (`constraints/cloudbuild.allowedIntegrations`)\nfor integrations using Google Cloud console\nand the `gcloud` command-line tool.\n\nBefore you Begin\n\n-\n\n\n Enable the Cloud Build and Organization Policy APIs.\n\n\n [Enable the APIs](https://console.cloud.google.com/flows/enableapi?apiid=cloudbuild.googleapis.com, orgpolicy.googleapis.com&redirect=https://cloud.google.com/build/docs/securing-builds/limit-builds-external-services)\n- To use the command-line examples in this guide, install and\n configure the [Google Cloud SDK](/sdk).\n\n | **Note:** If you've installed Google Cloud SDK previously, make sure you have the latest available version by running `gcloud components update`.\n- To set, change, or delete an organization policy, you must have the\n Organization Policy Administrator (`roles/orgpolicy.policyAdmin`) role. To\n learn how to add the role to your account, see [Add an organization policy administrator](/../resource-manager/docs/organization-policy/using-constraints#add-org-policy-admin).\n\nSetting up organization policy for allowed integrations\n\nThis section explains how you can set up the organization policy\n(`constraints/cloudbuild.allowedIntegrations`) to define builds for\nallowed integrations. \n\nConsole\n\n1. Open the **Organization policies** page in the Google Cloud console.\n\n [Open the Organization policies page](https://console.cloud.google.com/iam-admin/orgpolicies)\n2. Click on the row containing the **Allowed Integrations (Cloud Build)** policy.\n\n You will see the **Policy details** page.\n3. To edit the policy, click **Edit**.\n\n You will see the **Edit policy** page.\n4. In the **Applies to** section, select **Customize** to set the\n definition for your policy.\n\n5. In the **Policy enforcement** section, select **Replace** to define\n your own rules for the policy. Otherwise, select **Merge with parent**\n to ensure that rules at the parent resource are applied to your\n settings. To learn more, see [Understanding hierarchy evaluation](/../resource-manager/docs/organization-policy/understanding-hierarchy).\n\n6. In the **Rules** section, click **Add rule** to add a new rule for\n your policy.\n\n7. Under **Policy values** , select **Allow all** to allow builds\n from all services, select **Deny all** to deny builds from all\n services, or select **Custom** to allow or deny builds from\n specific services.\n\n If you select **Custom** as your value, complete the following steps:\n 1. In the **Policy type** section, select **Allow** or **Deny**.\n\n 2. In the **Custom values** section, enter the host URL of the instance\n or repository you want to allow or deny builds from. For example,\n to allow or deny builds from GitHub, enter your URL as `github.com`\n or `www.github.com`.\n\n You can also enter multiple URLs separated by a space. For\n example, `github.com ghe.staging-test.com`.\n\n Based on the event, the host URL you specify is one of the\n following:\n - RepoSync event: The host is `source.developers.google.com`.\n - GitHub app event: The host is derived from the `repository.html_url` field in your JSON payload, which is always `github.com`.\n - GitHub Enterprise event: The host is derived from the `repository.html_url` field in your JSON payload. For example, `ghe.staging-test.com`.\n - Pub/Sub event: The host is derived from the source specified in your trigger. If there is no source specified in your trigger, there is no organization policy check.\n - Webhook event: The host is derived from the source specified in your trigger. If there is no source specified in your trigger, there is organization policy check.\n\n | **Note:** You can enter any characters in the **Custom values** section except colons (`:`) and forward slashes (`/`).\n8. To save your rule, click **Done**.\n\n9. To add another rule, click **Add rule** . Otherwise, to save\n your policy, click **Save**.\n\ngcloud\n\n1. Open a terminal window.\n\n2. If you want to allow or deny builds from all services, create a YAML\n file with the following contents:\n\n name: projects/\u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e/policies/cloudbuild.allowedIntegrations\n spec:\n inheritFromParent: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eINHERIT\u003c/span\u003e\u003c/var\u003e\n rules:\n - \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eALLOW_OR_DENY\u003c/span\u003e\u003c/var\u003e: true\n\n Where:\n - \u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e is your project number.\n - \u003cvar translate=\"no\"\u003eINHERIT\u003c/var\u003e is `true` if you want your policy rules to be inherited from the parent resource. Otherwise, `false`.\n - \u003cvar translate=\"no\"\u003eALLOW_OR_DENY\u003c/var\u003e is `allowAll` if you want to allow builds from all host URLs. Otherwise, `denyAll`.\n - \u003cvar translate=\"no\"\u003eHOST_URL\u003c/var\u003e is your host URL. For example, `github.com`. You can also specify additional URLs on the following lines.\n\n If you want to allow or deny builds from selected services, create a YAML\n file with the following contents: \n\n name: projects/\u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e/policies/cloudbuild.allowedIntegrations\n spec:\n inheritFromParent: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eINHERIT\u003c/span\u003e\u003c/var\u003e\n rules:\n - values:\n \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eALLOW_OR_DENY\u003c/span\u003e\u003c/var\u003e:\n \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eHOST_URL\u003c/span\u003e\u003c/var\u003e\n ...\n\n Where:\n - \u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e is your project number.\n - \u003cvar translate=\"no\"\u003eINHERIT\u003c/var\u003e is `true` if you want your policy rules to be inherited from the parent resource. Otherwise, `false`.\n - \u003cvar translate=\"no\"\u003eALLOW_OR_DENY\u003c/var\u003e is `allowedValues` if you want to specify host URLs to allow builds from. Otherwise, `deniedValues`.\n - \u003cvar translate=\"no\"\u003eHOST_URL\u003c/var\u003e is your host URL. For example, `github.com`. You can also specify additional URLs on the following lines.\n\n | **Note:** You can use any characters when specifying your host URL except colons (`:`) and forward slashes (`/`).\n3. Set your organization policy by running the following command, where\n \u003cvar translate=\"no\"\u003eFILE_NAME\u003c/var\u003e is the name of your YAML file:\n\n gcloud org-policies set-policy \u003cvar translate=\"no\"\u003eFILE_NAME\u003c/var\u003e\n\n4. To confirm that your policy has been set, run the following command,\n where \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e is your project ID:\n\n gcloud org-policies describe cloudbuild.allowedIntegrations --effective --project \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e\n\nTesting organization policy for allowed integrations\n\nThis section explains how you can test your organization policy\n(`constraints/cloudbuild.allowedIntegrations`) using build triggers.\n\n1. If you have not already done so, [create a build trigger](/build/docs/automating-builds/create-manage-triggers#build_trigger).\n\n2. Push a change to your source.\n\n3. If your policy is set up to allow builds from your source, you will be\n able to view build executions from your trigger on the [**Build history**](https://console.cloud.google.com/cloud-build/builds) page. Otherwise, your build will not execute. To\n view history for builds restricted by your policy definition, see\n the [**Logs Explorer**](https://console.cloud.google.com/logs/query)\n page for the JSON payload reason and the reason for denial.\n\nWhat's next\n\n- Learn to [create and manage build triggers](/build/docs/automating-builds/create-manage-triggers).\n- Learn to [gate builds on approval](/build/docs/automating-builds/approve-builds).\n- Learn about [the permissions required to view build logs](/build/docs/securing-builds/store-view-build-logs).\n- Learn about [audit logs created by Cloud Build](/build/docs/securing-builds/audit-logs)."]]
