[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\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)."]]