Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Com o Cloud Build, é possível definir uma política da organização
(constraints/cloudbuild.allowedIntegrations) para controlar
quais serviços externos podem invocar gatilhos de build. Por exemplo, se o gatilho detectar mudanças em um repositório do GitHub e o GitHub for negado na política da organização, o gatilho não será executado. É possível especificar qualquer número de valores permitidos ou negados para sua organização ou projeto.
Nesta página, explicamos como configurar a política da organização (constraints/cloudbuild.allowedIntegrations) para integrações usando o console do Google Cloud e a ferramenta de linha de comando gcloud.
Antes de começar
Enable the Cloud Build and Organization Policy APIs.
Para usar os exemplos de linha de comando deste guia, instale e
configure o SDK Google Cloud.
Para definir, alterar ou excluir uma política da organização, você precisa ter o papel de Administrador da política da organização (roles/orgpolicy.policyAdmin). Para
saber como adicionar a função à sua conta, consulte Adicionar um administrador de política da organização.
Como configurar a política da organização para integrações permitidas
Esta seção explica como configurar a política da organização (constraints/cloudbuild.allowedIntegrations) para definir builds para integrações permitidas.
Console
Abra a página Políticas da organização no console do Google Cloud .
Clique na linha que contém a política Integrações permitidas (Cloud Build).
A página Detalhes da política vai aparecer.
Para editar a política, clique em Editar.
A página Editar política vai aparecer.
Na seção Aplicável a, selecione Personalizar para definir a
definição da política.
Na seção Aplicação da política, selecione Substituir para definir suas próprias regras para a política. Caso contrário, selecione Mesclar com pai
para garantir que as regras do recurso pai sejam aplicadas às suas
configurações. Para saber mais, consulte Noções básicas sobre a avaliação da hierarquia.
Na seção Regras, clique em Adicionar regra para adicionar uma nova regra à sua política.
Em Valores da política, selecione Permitir todos para permitir builds
de todos os serviços, Negar todos para negar builds de todos os
serviços ou Personalizado para permitir ou negar builds de
serviços específicos.
Se você selecionar Personalizado como valor, siga estas etapas:
Na seção Tipo de política, selecione Permitir ou Negar.
Na seção Valores personalizados, insira o URL do host da instância
ou do repositório de que você quer permitir ou negar builds. Por exemplo, para permitir ou negar builds do GitHub, insira o URL como github.com ou www.github.com.
Também é possível inserir vários URLs separados por um espaço. Por exemplo, github.com ghe.staging-test.com.
Com base no evento, o URL do host especificado é um dos seguintes:
Evento do RepoSync: o host é source.developers.google.com.
Evento do app GitHub: o host é derivado do campo repository.html_url no payload JSON, que é sempre github.com.
Evento do GitHub Enterprise: o host é derivado do campo repository.html_url no payload JSON. Por exemplo, ghe.staging-test.com.
Evento do Pub/Sub: o host é derivado da origem especificada no gatilho. Se não houver uma origem especificada no gatilho, não haverá uma verificação da política da organização.
Evento de webhook: o host é derivado da origem especificada no gatilho. Se não houver uma origem especificada no gatilho, haverá uma verificação da política da organização.
Para salvar a regra, clique em Concluído.
Para adicionar outra regra, clique em Adicionar regra. Caso contrário, para salvar
sua política, clique em Salvar.
gcloud
Abra uma janela de terminal.
Se quiser permitir ou negar builds de todos os serviços, crie um arquivo YAML
com o seguinte conteúdo:
Se a política estiver configurada para permitir builds da sua origem, será possível ver as execuções de build do gatilho na página Histórico de builds. Caso contrário, o build não será executado. Para
ver o histórico de builds restritos pela definição de política, consulte
a página do Explorador de registros
para o motivo do payload JSON e da recusa.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-18 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)."]]
