Conta de serviço padrão do Cloud Build

Dependendo das configurações da sua organização, o Cloud Build pode usar a conta de serviço padrão do Compute Engine ou a conta de serviço legado do Cloud Build para executar builds em seu nome.

As contas de serviço padrão podem ter permissões que são desnecessariamente amplas para seu caso de uso. Você pode melhorar sua postura de segurança seguindo o 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.

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.

Sobre a conta de serviço padrão do Compute Engine

As políticas da sua organização podem definir a conta de serviço padrão do Cloud Build como a conta de serviço padrão do Compute Engine. O endereço de e-mail dessa conta de serviço é
[PROJECT_NUMBER]-compute@developer.gserviceaccount.com.

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

Sobre a conta de serviço legada do Cloud Build

As políticas da sua organização podem definir a conta de serviço padrão do Cloud Build como a conta de serviço legada. O e-mail da conta de serviço legada do Cloud Build é
[PROJECT_NUMBER]@cloudbuild.gserviceaccount.com

Esta seção explica todas as permissões que a conta de serviço legada do Cloud Build tem por padrão.

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

Se as configurações do projeto permitirem o uso da conta de serviço legada do Cloud Build, ela vai receber o papel de conta de serviço do Cloud Build (roles/cloudbuild.builds.builder) para os recursos no projeto. Esse papel contém várias permissões, como a capacidade de atualizar versões ou gravar registros. A conta de serviço usa essas permissões somente conforme necessário para realizar ações ao executar a versão. Por exemplo, a conta de serviço usa a permissão artifactregistry.dockerimages.get para receber uma imagem do Docker do Artifact Registry, se o build estiver configurado para isso.

Se você não pretende executar uma ação como parte do processo de build, recomendamos que revogue a permissão correspondente da conta de serviço para obedecer ao [princípio de segurança do privilégio mínimo][privilégio mínimo].

A tabela a seguir lista as permissões que o papel da conta de serviço do Cloud Build (roles/cloudbuild.builds.builder) contém e a finalidade para a qual a conta de serviço do Cloud Build legada usa essas permissões.

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 Pode usar um pool particular Obrigatório para executar builds em um pool particular.
logging.logEntries.create Pode gravar registros Necessário para criar e listar registros de 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 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 do Docker do Artifact Registry
artifactregistry.dockerimages.list Pode listar imagens do 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 um local para um recurso no Artifact Registry
artifactregistry.locations.list Pode listar locais com suporte para 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 receber configurações de 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 de 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 build, é necessário escolher 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 legada 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 de editor do Cloud Build pode atualizar um gatilho, desde que ele esteja usando a conta de serviço legada do Cloud Build.

  • 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 para autenticação da conta de serviço.

Privilégios de gatilhos no momento do build

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 às contas de serviço especificadas pelo usuário. Tenha em mente as seguintes implicações de segurança ao usar gatilhos de build:

  • Um usuário sem acesso ao projeto do Google Cloud, mas com acesso de gravação ao 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 um gatilho quando enviam 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 na conta de serviço legada do Cloud Build

  • 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. Não é possível usar a conta de serviço legado do Cloud Build 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 de serviço a serviço.

  • Não é possível adicionar uma vinculação de política do IAM à conta de serviço legada. Por exemplo, não é possível criar uma vinculação de política do IAM que conceda a outra conta de serviço o papel roles/iam.serviceAccountTokenCreator na conta de serviço legado.

A seguir