O Gate se baseia 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 gatilhos de compilação. Por exemplo, se o gatilho detectar alterações 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

  • Ative as APIs Cloud Build and Organization Policy.

    Ative as 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 ter o papel de Administrador de políticas da organização (roles/orgpolicy.policyAdmin). Para saber como adicionar o papel à sua conta, consulte Adicionar um administrador de política da organização.

Como configurar a política da organização para integrações permitidas

Nesta seção, explicamos 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).

    A página Detalhes da política vai aparecer.

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

    A página Editar política será aberta.

  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 às 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 regra à sua política.

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

    Se você selecionar Personalizado como seu valor, siga estas 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 em que você quer permitir ou negar builds. Por exemplo, para permitir ou negar builds do GitHub, digite seu 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 do 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 seu payload JSON. Por exemplo, ghe.staging-test.com.
      • Evento do Pub/Sub: o host é derivado da origem especificada no seu gatilho. Se não houver uma fonte especificada no gatilho, não haverá verificação da política da organização.
      • Evento de webhook: o host é derivado da origem especificada no acionador. Se não houver uma fonte especificada no gatilho, há uma verificação da política da organização.

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

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

gcloud

  1. Abra uma janela de terminal.

  2. Para permitir ou negar builds de todos os serviços, crie um arquivo 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 as regras de política sejam herdadas do recurso pai. Caso contrário, false.
    • ALLOW_OR_DENY será allowAll se você quiser permitir builds de todos os URLs de host. Caso contrário, denyAll.
    • HOST_URL é o URL do seu host. Por exemplo, github.com. Você também pode especificar URLs adicionais nas linhas a seguir.

    Para permitir ou negar builds dos 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 as regras de política sejam herdadas do recurso pai. Caso contrário, false.
    • ALLOW_OR_DENY é allowedValues se você quiser especificar URLs de host para permitir builds. Caso contrário, deniedValues.
    • HOST_URL é o URL do seu host. Por exemplo, github.com. Você também pode especificar URLs adicionais nas linhas a seguir.

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

     gcloud org-policies set-policy FILE_NAME

  4. Para confirmar se 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 integrações permitidas

Nesta seção, explicamos como testar a política da organização (constraints/cloudbuild.allowedIntegrations) usando gatilhos de compilação.

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

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

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

A seguir