Contas de serviço do Cloud Deploy

Neste documento, descrevemos as contas de serviço usadas para executar o Cloud Deploy e como chamá-lo para executar várias operações.

O Cloud Deploy usa duas contas de serviço:

O agente de serviço do Cloud Deploy

O Cloud Deploy usa essa conta de serviço para interagir com o projeto. Não é possível substituir esse agente de serviço por uma conta de serviço alternativa, mas é possível editar permissões nele, por exemplo, quando você usa recursos fora do projeto, como uma conta de serviço ou um pool de workers particular do Cloud Build.
A conta de serviço de execução do Cloud Deploy

O Cloud Deploy usa essa conta de serviço para executar operações de renderização e implantação no Cloud Build. Essa conta precisa de permissões suficientes para ler e gravar no bucket do Cloud Storage e acessar os destinos de implantação.

A conta de serviço padrão para execução é a conta de serviço padrão do Compute Engine. É possível especificar uma conta de serviço alternativa na configuração de destino.
A conta de serviço de automação do Cloud Deploy

Essa é a conta de serviço que o Cloud Deploy usa para executar automações. Pode ser a conta de serviço de execução padrão ou outra conta de serviço. Consulte A conta de serviço de automação. Para mais informações sobre essa conta de serviço.

Consulte Como criar e gerenciar contas de serviço para ver instruções sobre como editar as permissões de uma conta de serviço e criar uma conta de serviço alternativa.

Agente de serviço do Cloud Deploy

O agente de serviço do Cloud Deploy é uma conta de serviço que o Cloud Deploy usa para interagir com outros serviços do Google Cloud dos quais o Cloud Deploy depende. Esses serviços incluem os registros de auditoria do Cloud Build, Pub/Sub e Cloud Audit Logs.

O nome dessa conta de serviço segue este padrão:

service-<project-number>@gcp-sa-clouddeploy.iam.gserviceaccount.com

Não é possível substituir o agente de serviço por uma conta de serviço alternativa. No entanto, talvez você precise adicionar permissões, por exemplo, para permitir o acesso a um pool particular em outro projeto, configurado como parte de um ambiente de execução.

Conta de serviço de execução do Cloud Deploy

Por padrão, o Cloud Deploy é executado usando a conta de serviço padrão do Compute Engine. Essa conta de serviço tem permissões suficientes no projeto que a contém para renderizar manifestos e implantar nos destinos.

O nome dessa conta de serviço segue este padrão:

[project-number]-compute@developer.gserviceaccount.com

Essa conta de serviço padrão tem permissões amplas. A prática recomendada é alterar o ambiente de execução para que o Cloud Deploy seja executado como uma conta de serviço diferente. É possível alterar a conta de serviço de execução para cada destino usando a propriedade executionConfigs.privatePool.serviceAccount ou a propriedade executionConfigs.defaultPool.serviceAccount na definição de destino.

Qualquer conta de serviço definida para essas propriedades precisa ter o papel roles/clouddeploy.jobRunner no projeto do Cloud Deploy. Se a conta de serviço de execução padrão não tiver essa permissão, execute o seguinte comando:

 gcloud projects add-iam-policy-binding PROJECT_ID \
     --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
     --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
     --role="roles/clouddeploy.jobRunner"

Quais contas de serviço criar

Se você optar por não usar a conta de serviço de execução padrão para renderização e implantação, será necessário criar uma ou mais contas de serviço alternativas para usar. Estas são as contas de serviço em que o Cloud Deploy é executado e estão configuradas na configuração de destino.

Um motivo para criar mais de um é ter uma conta de serviço específica ou contas para implantar em destinos restritos, como um destino de produção.

Uma abordagem possível é usar contas de serviço separadas por pipeline de entrega. Cada conta de serviço incluiria papéis com permissões suficientes para renderizar e implantar.

Para implantações no Google Kubernetes Engine, é possível restringir a conta de serviço a um namespace.

Como usar contas de serviço de um projeto diferente

Para o ambiente de execução, especifique uma conta de serviço que esteja em um projeto diferente daquele em que você criou o destino:

No projeto que é proprietário da conta de serviço, ative a política da organização SA entre projetos.
Conceda ao agente de serviço do Cloud Deploy (service-<project-number>@gcp-sa-clouddeploy.iam.gserviceaccount.com) a permissão iam.serviceAccounts.actAs para sua conta de serviço.

Nesse caso, project-number é o projeto em que você criou o destino.

Também é possível conceder o papel roles/iam.serviceAccountUser, que inclui essa permissão, no projeto de e em cada conta de serviço que está em um projeto diferente daquele em que o Cloud Deploy está sendo executado.
Conceda ao agente de serviço do Cloud Build (service-<project-number>@gcp-sa-cloudbuild.iam.gserviceaccount.com) o papel roles/iam.serviceAccountTokenCreator.

Nesse caso, project-number é o projeto em que você criou o destino, e esse papel é concedido no projeto da conta de serviço.

Conceda esse papel para cada conta de serviço configurada no ambiente de execução de um destino, caso essa conta esteja em um projeto diferente daquele em que o Cloud Deploy está sendo executado.
Conceda ao autor da chamada de gcloud deploy releases create e gcloud deploy rollouts create a permissão iam.serviceAccounts.actAs na conta de serviço ou o papel [roles/iam.serviceAccountUser](/iam/docs/understanding-roles#service-accounts-roles).

Permissões necessárias

A conta de serviço usada para renderizar as configurações precisa ter permissões suficientes para acessar o bucket do Cloud Storage em que os recursos do Cloud Deploy são armazenados (pipelines de entrega, versões, lançamentos).

O papel roles/clouddeploy.jobRunner inclui todas as permissões que a conta de serviço de renderização (privatePool ou defaultPool) precisa.
A conta de serviço usada para implantação precisa ter permissões suficientes para implantar no cluster de destino e permissão para acessar o bucket do Cloud Storage.

Observação: se você usar um bucket personalizado do Cloud Storage, poderá colocá-lo em qualquer lugar. Ele não precisa estar na mesma região, por exemplo, no pipeline de entrega.
A conta de serviço que chama o Cloud Deploy para criar uma versão precisa ter o papel clouddeploy.releaser. Ela também precisa ter a permissão iam.serviceAccount.actAs para usar a conta de serviço que renderiza os manifestos (por exemplo, por meio do papel roles/iam.serviceAccountUser).
A conta de serviço que chama o Cloud Deploy para promover uma versão ou criar um rollout precisa ter a permissão iam.serviceAccount.actAs para usar a conta de serviço implantada nos destinos (por exemplo, por meio do papel roles/iam.serviceAccountUser).
A conta de serviço configurada para uma automação precisa ter permissão para executar as operações que estão sendo automatizadas. Saiba mais.

A conta de serviço de automação

É possível automatizar algumas ações em uma versão. O Cloud Deploy executa essas automações usando a conta de serviço de automação, que pode ser a conta de serviço de execução padrão, uma conta de serviço não padrão usada como a conta de serviço de execução ou outra conta de serviço.

Essa conta de serviço é descrita na seção A conta de serviço de automação.

A seguir

Saiba mais sobre IAM.
Saiba mais sobre os papéis predefinidos do Cloud Deploy.
Entenda como criar e gerenciar contas de serviço.