O bloqueio é baseado na política da organização

O Cloud Build permite definir uma política da organização (constraints/cloudbuild.allowedIntegrations) para controlar quais serviços externos podem invocar acionadores de build. Por exemplo: se o gatilho detectar alterações em um repositório do GitHub e no GitHub for negado na política da organização, seu gatilho não será executado. É possível especificar qualquer número de valores permitidos ou negados para sua organização ou projeto.

Esta página explica 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.

    Enable the APIs

  • Para usar os exemplos de linha de comando neste guia, instale e configure o SDK Google Cloud.

  • Para definir, alterar ou excluir uma política da organização, você precisa do Papel de Administrador de políticas da organização (roles/orgpolicy.policyAdmin). Para aprender a adicionar a função à sua conta, consulte Adicionar um administrador de políticas da organização.

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

  1. Abra a página Políticas da organização no console do Google Cloud.

    Abrir a página "Políticas da organização"

  2. Clique na linha que contém a política Integrações permitidas (Cloud Build).

    Você verá a página Detalhes da política.

  3. Para editar a política, clique em Editar.

    Você verá a página Editar política.

  4. Na seção Aplicável a, selecione Personalizar para definir a definição da política.

  5. 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 no recurso pai sejam aplicadas configurações. Para saber mais, consulte Noções básicas sobre a avaliação da hierarquia.

  6. Na seção Regras, clique em Adicionar regra para adicionar uma nova a sua política.

  7. Em Valores da política, selecione Permitir todos para permitir builds em todos os serviços, selecione Negar todos para negar os builds de todos serviços, ou selecione Personalizado para permitir ou negar builds serviços específicos.

    Se você selecionar Personalizado como seu valor, conclua as seguintes etapas:

    1. Na seção Tipo de política, selecione Permitir ou Negar.

    2. Na seção Valores personalizados, insira o URL do host da instância ou do repositório 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.

      Você também pode 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 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 especificado no gatilho. Se não houver fonte no gatilho, não há organização e a verificação da política.
      • Evento de webhook: o host é derivado da origem especificado no gatilho. Se não houver uma origem especificada no acionador, haverá uma verificação da política da organização.

  8. Para salvar a regra, clique em Concluído.

  9. Para adicionar outra regra, clique em Adicionar regra. Caso contrário, para salvar sua política, clique em Salvar.

gcloud

  1. Abra uma janela de terminal.

  2. Se você quiser permitir ou negar builds de todos os serviços, crie um YAML com o seguinte conteúdo:

    name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
spec:
  inheritFromParent: INHERIT
  rules:
    - ALLOW_OR_DENY: true

    Em que:

    • PROJECT_NUMBER é o número do projeto.
    • INHERIT será true se você quiser que suas regras de política sejam herdados do recurso pai. Caso contrário, false.
    • ALLOW_OR_DENY vai ser allowAll se você quiser para permitir builds de todos os URLs de host. Caso contrário, denyAll.
    • HOST_URL é o URL do host. Por exemplo, github.com. Você também pode especificar outros URLs nas linhas a seguir.

    Se você quiser permitir ou negar builds de serviços selecionados, crie um arquivo YAML com o seguinte conteúdo:

    name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
spec:
  inheritFromParent: INHERIT
  rules:
    - values:
        ALLOW_OR_DENY:
          HOST_URL
          ...

    Em que:

    • PROJECT_NUMBER é o número do projeto.
    • INHERIT será true se você quiser que suas regras de política sejam herdados do recurso pai. Caso contrário, false.
    • ALLOW_OR_DENY vai ser allowedValues se você quiser para especificar URLs de host para permitir builds. Caso contrário, deniedValues.
    • HOST_URL é o URL do host. Por exemplo, github.com. Você também pode especificar outros URLs nas linhas a seguir.

  3. Execute o comando a seguir para definir a política da organização, em que FILE_NAME é o nome do arquivo YAML:

     gcloud org-policies set-policy FILE_NAME

  4. Para confirmar que a política foi definida, execute o comando a seguir, em que PROJECT_ID é o ID do projeto:

     gcloud org-policies describe cloudbuild.allowedIntegrations --effective --project PROJECT_ID

Testar a política da organização para verificar as integrações permitidas

Esta seção explica como testar a política da sua organização (constraints/cloudbuild.allowedIntegrations) usando gatilhos de build.

  1. Crie um gatilho de build se ainda não tiver feito isso.

  2. Envie uma alteração para a origem.

  3. Se a política estiver configurada para permitir builds da sua origem, você poderá acessar as execuções de build do acionador na página Histórico de builds. Caso contrário, seu build não será executado. Para acessar o histórico de builds restritos pela definição da política, consulte a página Logs Explorer para conferir o motivo do payload JSON e o motivo da recusa.

A seguir