O Cloud Build permite 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 estiver escutando 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 Google Cloud o console do Google Cloud
e a ferramenta de linha de comando gcloud.
Antes de começar
-
Ative as APIs Cloud Build e Organization Policy.
Funções necessárias para ativar APIs
Para ativar as APIs, é necessário ter a permissão
serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de proprietário (roles/owner). Caso contrário, você pode receber essa permissão pelo papel de administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis. 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 Administrador da Política 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
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 Google Cloud console.
Clique na linha que contém a política Integrações permitidas (Cloud Build).
A página Detalhes da política será exibida.
Para editar a política, clique em Editar.
A página Editar política será exibida.
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 o pai para garantir que as regras no 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 à política.
Em Valores da 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 valor, conclua as etapas a seguir:
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 em que você quer permitir ou negar builds. Por exemplo, para permitir ou negar builds do GitHub, insira o URL como
github.comouwww.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_urlno payload JSON, que é sempregithub.com. - Evento do GitHub Enterprise: o host é derivado do campo
repository.html_urlno payload JSON. Por exemplo,ghe.staging-test.com. - Evento do Pub/Sub: o host é derivado da origem especificada no gatilho. Se nenhuma origem for especificada no gatilho, não haverá verificação de política da organização.
- Evento de webhook: o host é derivado da origem especificada no gatilho. Se nenhuma origem for especificada no gatilho, não haverá verificação de política da organização.
- Evento do RepoSync: o host é
Para salvar a regra, clique em Concluído.
Para adicionar outra regra, clique em Adicionar regra. Caso contrário, para salvar a política, clique em Salvar.
gcloud
Abra uma janela do terminal.
Se você quiser 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: trueEm que:
PROJECT_NUMBERé o número do projeto.INHERITétruese você quiser que as regras de política sejam herdadas do recurso pai. Caso contrário,false.ALLOW_OR_DENYéallowAllse você quiser permitir builds de todos os URLs de host. Caso contrário,denyAll.HOST_URLé o URL do host. Por exemplo,github.com. Também é possível 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étruese você quiser que as regras de política sejam herdadas do recurso pai. Caso contrário,false.ALLOW_OR_DENYéallowedValuesse você quiser especificar URLs de host para permitir builds. Caso contrário,deniedValues.HOST_URLé o URL do host. Por exemplo,github.com. Também é possível especificar outros URLs nas linhas a seguir.
Defina a política da organização executando o seguinte comando, em que FILE_NAME é o nome do arquivo YAML:
gcloud org-policies set-policy FILE_NAMEPara confirmar se a política foi definida, execute o seguinte comando, em que PROJECT_ID é o ID do projeto:
gcloud org-policies describe cloudbuild.allowedIntegrations --effective --project PROJECT_ID
Como testar a política da organização para integrações permitidas
Esta seção explica como testar a política da organização
(constraints/cloudbuild.allowedIntegrations) usando gatilhos de build.
Crie um gatilho de build, caso ainda não tenha feito isso. Crie um gatilho de build.
Envie uma mudança para sua origem.
Se a política estiver configurada para permitir builds da sua origem, será possível visualizar as execuções de build do gatilho na página Histórico de builds. Caso contrário, o build não será executado. Para visualizar o histórico de builds restritos pela definição de política, consulte a página Logs Explorer para conferir o motivo do payload JSON e o motivo da negação.
A seguir
- Aprenda a criar e gerenciar gatilhos de build.
- Aprenda a bloquear builds na aprovação.
- Saiba mais sobre as permissões necessárias para visualizar os registros de build.
- Saiba mais sobre registros de auditoria criados pelo Cloud Build.