Contas de serviço do Cloud Deploy

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

O Cloud Deploy usa as seguintes contas de serviço:

  • O agente de serviço do Cloud Deploy

    O Cloud Deploy usa essa conta de serviço para interagir com seu 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 realizar 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 em que 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.

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

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

Como essa conta de serviço é usada por muitos produtos, ela pode ter permissões amplas. A prática recomendada é mudar o ambiente de execução para que o Cloud Deploy seja executado como uma conta de serviço diferente. É possível mudar a conta de serviço de execução para cada destino usando a propriedade executionConfigs.privatePool.serviceAccount ou a executionConfigs.defaultPool.serviceAccount na definição de destino.

Qualquer conta de serviço definida para essas propriedades precisa ter o papel Cloud Deploy Runner no projeto do Cloud Deploy. Se a conta de serviço de execução padrão não tiver esse papel, 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"

A conta de serviço também vai precisar de permissões específicas do ambiente de execução para implantar no ambiente de execução escolhido. No Google Kubernetes Engine, você pode escolher os papéis Desenvolvedor de contêineres e Usuário da conta de serviço. Para o Cloud Run, você pode escolher os papéis Desenvolvedor do Cloud Run e Usuário da conta de serviço. Outros ambientes de execução usados por Alvos personalizados podem exigir as próprias permissões.

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. Essas são as contas de serviço nas quais 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, é possível especificar uma conta de serviço em um projeto diferente daquele em que você cria o destino:

  1. No projeto proprietário da conta de serviço, ative a política da organização de SA entre projetos.

  2. Conceda ao agente de serviço (service-<project-number>@gcp-sa-clouddeploy.iam.gserviceaccount.com) do Cloud Deploy a permissão iam.serviceAccounts.actAs para sua conta de serviço.

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

    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.

  3. 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.

    É necessário conceder esse papel a cada conta de serviço configurada no ambiente de execução de um destino se essa conta de serviço estiver em um projeto diferente daquele em que o Cloud Deploy está sendo executado.

  4. Conceda a permissão iam.serviceAccounts.actAs ao autor da chamada de gcloud deploy releases create e gcloud deploy rollouts create na conta de serviço ou o papel roles/iam.serviceAccountUser.

Permissões necessárias

  • A conta de serviço usada para renderizar configurações precisa ter permissões suficientes para acessar o bucket do Cloud Storage em que os recursos do Cloud Deploy estã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.

  • A conta de serviço que chama o Cloud Deploy para criar uma versão precisa ter o papel clouddeploy.releaser. Ele também precisa ter a permissão iam.serviceAccount.actAs para usar a conta de serviço que renderiza manifestos (por exemplo, pelo papel roles/iam.serviceAccountUser).

  • A conta de serviço que chama o Cloud Deploy para promover uma versão ou criar uma rollout precisa ter a permissão iam.serviceAccount.actAs para usar a conta de serviço que implanta em destinos (por exemplo, pelo 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.

Saiba mais sobre a conta de serviço de automação.

A seguir