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 nos em nome da empresa. 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 padrão de serviço podem ter permissões que são desnecessariamente 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 no seu em nome da empresa. Isso pode reduzir o possível impacto de configurações incorretas ou usuários.

Nesta página, explicamos todas as permissões concedidas por 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ários como permissões de atualização de builds ou gravação de 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 Pode usar um pool particular Necessário para executar builds em um pool privado.
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 do Docker do Artifact Registry
artifactregistry.dockerimages.list Pode listar imagens Docker armazenadas no Artifact Registry
artifactregistry.kfpartifacts.create Pode fazer upload de um artefato 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 com suporte para o Artifact Registry
artifactregistry.mavenartifacts.get Pode receber pacotes Maven do Artifact Registry
artifactregistry.mavenartifacts.list Pode listar pacotes 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 É possível criar um repositório gcr.io no Artifact Registry na primeira vez que um é 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 build, escolha a conta de serviço usada para executar o build. É possível configurar cada gatilho a uma conta de serviço diferente. A única exceção é se as o projeto tem a conta de serviço legada do Cloud Build ativada, Nesse caso, o build aciona por padrão o uso da conta de serviço legada quando não há a outra conta está selecionada.

Acesso do usuário aos gatilhos

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

  • Conta de serviço legada do Cloud Build (se ativada): Qualquer usuário com o papel 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 padrão do Compute Engine: Qualquer usuário com o papel de Editor do Cloud Build que 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 dar essa permissão a um usuário, você pode concedê-lo um papel predefinido com a permissão, como o papel Usuário da conta de serviço (roles/iam.serviceAccountUser). Como alternativa, é possível criar um papel do IAM com a permissão iam.serviceAccounts.actAs, conceder o 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 tempo de build dos gatilhos

A conta de serviço configurada para um gatilho de compilação pode fornecer elevou as permissões de tempo de build para os usuários que empregam 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