Stay organized with collections
Save and categorize content based on your preferences.
Cloud Build enables you to define an organization policy
(constraints/cloudbuild.allowedIntegrations) to control
which external services can invoke build triggers. For example,
if your trigger listens for changes to a GitHub repository and GitHub
is denied in the organization policy, your trigger will not run. You can specify
any number of allowed or denied values for your organization or project.
This page explains how you can set up the organization policy (constraints/cloudbuild.allowedIntegrations)
for integrations using Google Cloud console
and the gcloud command-line tool.
Before you Begin
Enable the Cloud Build and Organization Policy APIs.
To use the command-line examples in this guide, install and
configure the Google Cloud SDK.
To set, change, or delete an organization policy, you must have the
Organization Policy Administrator (roles/orgpolicy.policyAdmin) role. To
learn how to add the role to your account, see Add an organization policy administrator.
Setting up organization policy for allowed integrations
This section explains how you can set up the organization policy
(constraints/cloudbuild.allowedIntegrations) to define builds for
allowed integrations.
Console
Open the Organization policies page in the Google Cloud console.
Click on the row containing the Allowed Integrations (Cloud Build) policy.
You will see the Policy details page.
To edit the policy, click Edit.
You will see the Edit policy page.
In the Applies to section, select Customize to set the
definition for your policy.
In the Policy enforcement section, select Replace to define
your own rules for the policy. Otherwise, select Merge with parent
to ensure that rules at the parent resource are applied to your
settings. To learn more, see Understanding hierarchy evaluation.
In the Rules section, click Add rule to add a new rule for
your policy.
Under Policy values, select Allow all to allow builds
from all services, select Deny all to deny builds from all
services, or select Custom to allow or deny builds from
specific services.
If you select Custom as your value, complete the following steps:
In the Policy type section, select Allow or Deny.
In the Custom values section, enter the host URL of the instance
or repository you want to allow or deny builds from. For example,
to allow or deny builds from GitHub, enter your URL as github.com
or www.github.com.
You can also enter multiple URLs separated by a space. For
example, github.com ghe.staging-test.com.
Based on the event, the host URL you specify is one of the
following:
RepoSync event: The host is source.developers.google.com.
GitHub app event: The host is derived from the repository.html_url field
in your JSON payload, which is always github.com.
GitHub Enterprise event: The host is derived from the repository.html_url field
in your JSON payload. For example, ghe.staging-test.com.
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.
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.
To save your rule, click Done.
To add another rule, click Add rule. Otherwise, to save
your policy, click Save.
gcloud
Open a terminal window.
If you want to allow or deny builds from all services, create a YAML
file with the following contents:
If your policy is set up to allow builds from your source, you will be
able to view build executions from your trigger on the Build history page. Otherwise, your build will not execute. To
view history for builds restricted by your policy definition, see
the Logs Explorer
page for the JSON payload reason and the reason for denial.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 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,["# Gate builds on organization policy\n\nCloud 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\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-------------------------------------------------------\n\nThis section explains how you can set up the organization policy\n(`constraints/cloudbuild.allowedIntegrations`) to define builds for\nallowed integrations. \n\n### Console\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\n### gcloud\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----------------------------------------------------\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\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)."]]