Conta de serviço padrão do Cloud Build

Dependendo das configurações do projeto, o Cloud Build pode usar a conta de serviço legada do Cloud Build ou a conta de serviço padrão do Compute Engine para executar builds em seu nome. O e-mail da conta de serviço legada do Cloud Build é [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com e o e-mail da conta de serviço padrão do Compute Engine é [PROJECT_NUMBER]-compute@developer.gserviceaccount.com. As contas de serviço padrão podem ter permissões muito amplas para seu caso de uso. Você pode melhorar sua postura de segurança seguindo as princípio de privilégio mínimo. Como parte desse princípio, recomendamos criar sua própria conta de serviço para executar builds em seu nome. Isso pode reduzir o impacto potencial de configurações incorretas ou usuários mal-intencionados.

Nesta página, explicamos todas as permissões que a conta de serviço legada do Cloud Build tem por padrão.

Para informações sobre a conta de serviço padrão do Compute Engine, consulte Conta de serviço padrão do Compute Engine

Para saber como conceder ou revogar permissões para as contas de serviço padrão do Cloud Build, consulte Configurar o acesso à conta de serviço padrão do Cloud Build.

Permissões padrão da conta de serviço legada do Cloud Build

Se as configurações do seu projeto permitirem o uso da versão legada do Cloud Build da conta de serviço, ela receberá a conta de serviço do Cloud Build para os recursos no projeto. Esse papel contém várias permissões, como a capacidade de atualizar builds ou gravar registros. O serviço usa essas permissões apenas quando necessário para realizar ações quando e executar seu build. Por exemplo, a conta de serviço usa artifactregistry.dockerimages.get para receber uma imagem do Docker de Container Registry, se o build estiver configurado para isso. Se você não planeja executar uma ação como parte do processo de compilação, recomendamos que você revogue o permissão correspondente da conta de serviço para obedecer princípio de segurança de privilégio mínimo.

A tabela a seguir lista as permissões que o papel da conta de serviço do Cloud Build contém e a finalidade dessas permissões para a conta.

Permissão Descrição Finalidade da permissão
cloudbuild.builds.create Pode criar builds e gatilhos Obrigatório para:
  • Use gatilhos de compilação.
  • Criar, listar, receber ou cancelar builds.
cloudbuild.builds.update Pode atualizar builds e gatilhos
cloudbuild.builds.list Pode listar builds e gatilhos
cloudbuild.builds.get Pode receber um build e um gatilho
cloudbuild.workerpools.use É possível usar um pool privado Obrigatório para executar builds em um pool particular.
logging.logEntries.create Pode gravar registros Necessário para criar e listar registros do build no Cloud Logging.
logging.logEntries.list Pode listar registros
logging.views.access Pode ver registros
pubsub.topics.create Pode criar tópicos do Pub/Sub Necessário para enviar atualizações do build ao Pub/Sub.
pubsub.topics.publish Pode publicar no Pub/Sub
remotebuildexecution.blobs.get Pode ter acesso para aprovar ou rejeitar builds. Necessário para aprovar ou rejeitar builds pendentes
resourcemanager.projects.get Pode receber informações do projeto
resourcemanager.projects.list Pode listar projetos
source.repos.get Pode ler o código-fonte dos repositórios no Cloud Source Repositories. Obrigatório para:
  • Usar gatilhos do Bitbucket e do Cloud Source Repositories.
  • Extrair o código-fonte do Cloud Source Repositories.
source.repos.list Pode listar repositórios no Cloud Source Repositories
storage.buckets.create Pode criar buckets do Cloud Storage Obrigatório para:
  • Armazenar e receber imagens no Container Registry ( descontinuado).
  • Armazenar e receber artefatos no Cloud Storage.
  • Enviar builds manualmente usando gcloud builds submit.
  • Armazenar registros de build no bucket de registros criado pelo usuário.
storage.buckets.get Pode receber buckets do Cloud Storage
storage.buckets.list Pode listar buckets do Cloud Storage
storage.objects.list Pode listar objetos do Cloud Storage
storage.objects.update Pode atualizar objetos do Cloud Storage
storage.objects.create Pode gravar objetos do Cloud Storage
storage.objects.delete Pode excluir objetos do Cloud Storage
storage.objects.get Pode ler objetos do Cloud Storage
artifactregistry.repositories.uploadArtifacts Pode fazer upload de artefatos para repositórios no Artifact Registry Necessário para gerenciar artefatos no Artifact Registry.
artifactregistry.repositories.downloadArtifacts Pode fazer o download de artefatos de um repositório no Artifact Registry
artifactregistry.aptartifacts.create Pode fazer upload de artefatos do Apt para o Artifact Registry
artifactregistry.dockerimages.get Pode receber imagens Docker do Artifact Registry
artifactregistry.dockerimages.list Pode listar imagens Docker armazenadas no Artifact Registry
artifactregistry.kfpartifacts.create Pode fazer upload de um artefato do KFP para o Artifact Registry
artifactregistry.locations.get Pode receber informações sobre a localização de um recurso no Artifact Registry
artifactregistry.locations.list Pode listar locais compatíveis com o Artifact Registry
artifactregistry.mavenartifacts.get Pode receber pacotes do Maven do Artifact Registry
artifactregistry.mavenartifacts.list Pode listar pacotes do Maven do Artifact Registry
artifactregistry.npmpackages.get Pode receber pacotes npm do Artifact Registry
artifactregistry.npmpackages.list Pode listar pacotes npm do Artifact Registry
artifactregistry.projectsettings.get Pode acessar as configurações do projeto do Artifact Registry
artifactregistry.pythonpackages.get Pode receber pacotes Python do Artifact Registry
artifactregistry.pythonpackages.list Pode listar pacotes Python do Artifact Registry
artifactregistry.yumartifacts.create Pode fazer upload de artefatos do Yum para o Artifact Registry
artifactregistry.repositories.createOnPush Pode criar um repositório gcr.io no Artifact Registry na primeira vez que uma imagem é enviada para um nome de host gcr.io no projeto.
artifactregistry.repositories.get Pode receber um repositório do Artifact Registry
artifactregistry.repositories.list Pode listar repositórios no Artifact Registry
artifactregistry.repositories.listEffectiveTags Pode listar tags para artefatos no Artifact Registry Necessário para gerenciar tags de artefatos no Artifact Registry.
artifactregistry.repositories.listTagBindings Pode listar informações de vinculação de tags para artefatos no Artifact Registry
artifactregistry.tags.create Pode criar tags no Artifact Registry
artifactregistry.tags.get Pode receber tags do Artifact Registry
artifactregistry.tags.list Pode listar tags no Artifact Registry
artifactregistry.tags.update Pode atualizar tags no Artifact Registry
artifactregistry.versions.list Pode listar versões no Artifact Registry
artifactregistry.versions.get Pode receber versões no Artifact Registry
containeranalysis.occurrences.create Pode criar uma ocorrência do Artifact Analysis A conta de serviço do Cloud Build não usa essas permissões, mas elas são incluídas para compatibilidade com versões anteriores.
containeranalysis.occurrences.delete Pode excluir uma ocorrência do Artifact Analysis
containeranalysis.occurrences.get Pode receber uma ocorrência do Artifact Analysis
containeranalysis.occurrences.list Pode listar ocorrências do Artifact Analysis
containeranalysis.occurrences.update Pode atualizar ocorrências do Artifact Analysis

Gatilhos de build

Ao criar gatilhos de compilação, escolha a conta de serviço usada para executar o build. É possível configurar cada gatilho com uma conta de serviço diferente. A única exceção é se o projeto tiver a conta de serviço legada do Cloud Build ativada. Nesse caso, os gatilhos de build vão usar a conta de serviço legada por padrão quando nenhuma outra conta for selecionada.

Acesso do usuário a acionadores

O acesso do usuário aos acionadores depende do tipo de conta de serviço configurado para o acionador:

  • Conta de serviço herdada do Cloud Build (se ativada): qualquer usuário com o papel de editor do Cloud Build pode criar e executar diretamente um gatilho. Por exemplo, um usuário pode executar o gatilho manualmente. Qualquer usuário com o papel Editor do Cloud Build pode atualizar desde que ele esteja usando o Cloud Build conta de serviço legada.

  • Conta de serviço especificada pelo usuário ou a conta de serviço padrão do Compute Engine: qualquer usuário com o papel de editor do Cloud Build que tenha a permissão iam.serviceAccounts.actAs pode criar e executar diretamente um gatilho. Por exemplo, um usuário pode executar o gatilho manualmente. Qualquer usuário com o papel de editor do Cloud Build pode atualizar um gatilho, desde que tenha as permissões iam.serviceAccounts.actAs na conta de serviço configurada anteriormente e na nova conta de serviço especificada no gatilho. Para conceder essa permissão a um usuário, conceda um papel predefinido com a permissão, como o papel de Usuário da conta de serviço (roles/iam.serviceAccountUser). Como alternativa, crie um papel IAM personalizado com a permissão iam.serviceAccounts.actAs e conceda esse papel ao usuário. Para saber mais sobre as permissões da conta de serviço, consulte Papéis de autenticação da conta de serviço.

Privilégios de tempo de build dos gatilhos

A conta de serviço configurada para um acionador de build pode oferecer permissões elevadas de tempo de build aos usuários que usam gatilhos para invocar um build. Isso se aplica à conta de serviço legada e ao serviço especificado pelo usuário contas de serviço. Lembre-se das seguintes implicações de segurança ao usar o build gatilhos:

  • Um usuário sem acesso ao seu projeto do Google Cloud, mas com acesso de gravação a o repositório associado aos gatilhos de build no projeto terá permissões para alterar o código que está sendo criado. Por exemplo, os usuários podem invocar indiretamente uma quando envia um novo código-fonte para um repositório conectado.

  • Além disso, se você estiver usando os gatilhos de solicitação de pull do GitHub, qualquer usuário com acesso de leitura ao repositório poderá enviar uma solicitação de pull, que pode acionar um build que inclua alterações no código na solicitação de envio. Você pode desativar esse comportamento escolhendo a opção Controle de comentários ao criar um gatilho de solicitação pull do GitHub. A seleção dessa opção garante que o build seja iniciado somente se um proprietário do repositório ou um colaborador fizerem comentários /gcbrun. Para saber mais sobre como usar o controle de comentários com gatilhos do GitHub, consulte Como criar gatilhos do GitHub.

Limitações

Se você precisar autenticar entre serviços usando um token de ID, execute seus builds com uma conta de serviço especificada pelo usuário. O Cloud Build a conta de serviço legada não pode ser usada para gerar tokens de ID.

Por exemplo, se você usa aplicativos de plataforma sem servidor, como funções do Cloud Run, Cloud Run ou App Engine, e quer invocar seu aplicativo no Cloud Build, é necessária uma conta de serviço especificada pelo usuário configurada com as permissões necessárias para a autenticação de serviço a serviço.

Para instruções, consulte Autorizar o acesso serviço a serviço.

A seguir