Como exigir permissão para anexar contas de serviço a recursos

Quando você cria determinados recursos do Google Cloud, tem a opção de anexar uma conta de serviço. A conta de serviço anexada funciona como a identidade de qualquer job em execução no recurso, permitindo que os jobs sejam autenticados nas APIs do Google Cloud.

Na maioria dos serviços do Google Cloud, os usuários precisam de permissão para personificar uma conta de serviço a fim de anexar essa conta a um recurso. Isso significa que o usuário precisa da permissão iam.serviceAccounts.actAs na conta de serviço.

No entanto, anteriormente, alguns serviços permitiam que os usuários anexassem contas de serviço a recursos, mesmo que eles não tivessem permissão para personificar as contas. Com essa configuração, os usuários desses serviços podem ganhar permissões elevadas e não óbvias.

Na tabela a seguir, listamos os serviços que tinham essa configuração e o comportamento legado de cada serviço:

Serviço	Comportamento legado
App Engine	Os usuários podiam implantar aplicativos do App Engine que usavam a identidade da conta de serviço padrão do App Engine, mesmo se não tivessem permissão para personificar essa conta.
Cloud Composer	Os usuários podiam anexar qualquer conta de serviço no projeto a um ambiente do Cloud Composer, mesmo que não tivessem permissão para personificar nenhuma das contas de serviço do projeto.
Cloud Data Fusion Dataflow Dataproc	Os usuários podiam anexar a conta de serviço padrão do Compute Engine aos recursos, mesmo se não tivessem permissão para personificar essa conta.

Agora, exigimos que esses serviços verifiquem se os usuários têm permissão para personificar as contas de serviço ao anexar essas contas aos recursos. No entanto, o comportamento legado ainda existe para os seguintes tipos de organização:

• Organizações com usuários que podem implantar aplicativos do App Engine, mas que não têm permissão para personificar a conta de serviço padrão do App Engine.
• Organizações com usuários que têm permissão para implantar ambientes do Cloud Composer, mas não têm permissão para personificar contas de serviço.
• Organizações com usuários que têm permissão para implantar recursos do Cloud Data Fusion, Dataflow ou Dataproc, mas não têm permissão para personificar a conta de serviço padrão do Compute Engine.

Se sua organização ainda for afetada pelo comportamento legado, você terá recebido uma comunicação explicando como desativá-la manualmente. Também é possível consultar as seções abaixo para instruções detalhadas.

Como proteger o App Engine

Para desativar manualmente o comportamento legado no App Engine, verifique se os usuários têm permissão para personificar a conta de serviço do App Engine. Em seguida, ative uma restrição na política da organização para fazer verificações de permissão da conta de serviço ao implantar aplicativos que usam a identidade da conta de serviço padrão do App Engine.

1. Opcional: use recomendações de papéis para diminuir com segurança o escopo das permissões da conta de serviço padrão do App Engine.

   Essa conta recebe automaticamente o papel de editor (roles/editor), que tem muitas permissões. No entanto, não recomendamos usar esse papel nas configurações de produção.

   Observação: para proteger ainda mais sua organização, é possível desativar concessões automáticas de papéis a contas de serviço.

2. Garanta que todos os usuários que implantam aplicativos possam personificar a conta de serviço padrão do App Engine.

   Para fornecer essa capacidade, conceda aos usuários um papel que inclua a permissão iam.serviceAccounts.actAs, como o papel de usuário da conta de serviço (roles/iam.serviceAccountUser). É possível conceder esse papel no projeto ou na conta de serviço padrão do App Engine. Para ver instruções, consulte Como gerenciar a personificação da conta de serviço.

   Observação: se você tiver um grande número de projetos, use o localizador de discrepâncias nas permissões (em inglês) para encontrar os usuários com permissão para implantar aplicativos, mas que não podem personificar a conta de serviço padrão do App Engine.

3. Ative a restrição na política da organização constraints/appengine.enforceServiceAccountActAsCheck para fazer verificações de permissão da conta de serviço ao implantar aplicativos.

   Observação: essa restrição da política da organização só é visível em ambientes com o comportamento legado. Se você não vir a restrição, ela já foi aplicada no seu ambiente.

4. Opcional: use o aplicador de políticas booleanas da organização (em inglês) para confirmar que a restrição na política da organização está sendo aplicada em todos os seus projetos.

Como proteger o Cloud Composer

Para desativar manualmente o comportamento legado do Cloud Composer, garanta que os usuários tenham permissão para personificar as contas de serviço anexadas aos novos ambientes. Em seguida, ative uma restrição na política da organização para fazer verificações de permissão da conta de serviço ao anexar contas desse tipo aos ambientes.

1. Identifique todas as contas de serviço vinculadas aos ambientes do Cloud Composer:

   1. No Console do Google Cloud, acesse a página Ambientes do Compose.

      Acessar a página "Ambientes do Composer"

   2. Clique no nome de um ambiente.

   3. Na guia Configuração do ambiente, localize o campo Conta de serviço e registre o nome dessa conta.

   4. Repita os passos anteriores para todos os ambientes do Cloud Composer no seu projeto.

2. Confirme se essas contas de serviço seguem o princípio do privilégio mínimo:

   • No Console do Google Cloud, acesse a página IAM, encontre as contas de serviço e revise os papéis.

     Acessar a página "IAM"

   • Se necessário, conceda um papel menos permissivo para a conta de serviço. É possível selecionar um papel na lista de Papéis predefinidos do IAM, use um papel sugerido por uma recomendação de papéis ou crie um papel personalizado.

3. Verifique se todos os usuários que implantam ou gerenciam ambientes do Cloud Composer podem representar as contas de serviço usadas pelos ambientes.

   Para fornecer essa capacidade, conceda aos usuários um papel que inclua a permissão iam.serviceAccounts.actAs, como o papel de usuário da conta de serviço (roles/iam.serviceAccountUser). É possível conceder esse papel no projeto ou em uma conta de serviço individual. Para ver instruções, consulte Como gerenciar a personificação da conta de serviço.

   Observação: se você tiver um grande número de projetos, use o localizador de discrepâncias nas permissões (em inglês) para encontrar os usuários com permissão para implantar ambientes do Cloud Composer, mas que não podem personificar as contas de serviço.

4. Ative a restrição na política da organização constraints/composer.enforceServiceAccountActAsCheck para fazer verificações de permissão da conta de serviço ao anexar contas de serviço aos ambientes.

   Observação: essa restrição da política da organização só é visível em ambientes com o comportamento legado. Se você não vir a restrição, ela já foi aplicada no seu ambiente.

5. Opcional: use o aplicador de políticas booleanas da organização (em inglês) para confirmar que a restrição na política da organização está sendo aplicada em todos os seus projetos.

Como proteger o Dataproc, o Dataflow e o Cloud Data Fusion

Para desativar manualmente o comportamento legado no Dataproc, no Dataflow e no Cloud Data Fusion, garanta que os usuários tenham permissão para personificar as contas de serviço anexadas aos novos recursos. Em seguida, ative as restrições na política da organização para fazer verificações de permissão da conta de serviço ao anexar contas de serviço aos recursos.

Siga as instruções para o tipo de conta de serviço que você quer anexar a novos recursos:

• Se você quiser parar de anexar a conta de serviço padrão do Compute Engine a novos recursos, siga estas etapas:

  Observação: no Cloud Data Fusion, o uso de contas de serviço diferentes da conta de serviço padrão do Compute Engine só está disponível para cliente do Cloud Data Fusion Enterprise. Para mais informações, consulte Contas de serviço do Cloud Data Fusion.

  1. Crie uma nova conta de serviço e conceda à conta de serviço os papéis necessários para executar jobs no recurso. Siga o princípio de privilégio mínimo.

     Para saber quais papéis uma conta de serviço precisa para executar jobs nos recursos do Dataproc, Dataflow e Cloud Data Fusion, consulte:

     • Requisitos da conta de serviço do Dataproc
     • Requisitos de conta de serviço do Dataflow
     • As contas de serviço do Cloud Data Fusion têm os mesmos requisitos que as contas de serviço do Dataproc.

  2. Permita que todos os usuários que implantem esses recursos personifiquem a nova conta de serviço.

     Para fornecer essa capacidade, conceda aos usuários um papel que inclua a permissão iam.serviceAccounts.actAs, como o papel de usuário da conta de serviço (roles/iam.serviceAccountUser). É possível conceder esse papel no projeto ou na conta de serviço. Para ver instruções, consulte Como gerenciar a personificação da conta de serviço.

  3. Ative as seguintes restrições na política da organização para fazer verificações de permissão da conta de serviço ao anexar contas de serviço aos recursos:

     • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
     • constraints/dataproc.enforceComputeDefaultServiceAccountCheck

     A restrição da política da organização constraints/dataproc.enforceComputeDefaultServiceAccountCheck também aplica verificações de permissão para o Cloud Data Fusion.

     Observação: essas restrições da política da organização só são visíveis em ambientes com o comportamento legado. Se você não vir as restrições, elas já foram aplicadas ao seu ambiente.

  4. Opcional: use o aplicador de políticas booleanas da organização (em inglês) para confirmar que as restrições na política da organização estão sendo aplicadas em todos os seus projetos.

  5. Ao implantar novos recursos, use a nova conta em vez da conta de serviço padrão do Compute Engine.

• Se você quiser continuar anexando a conta de serviço padrão do Compute Engine a novos recursos, siga estes passos:

  1. Opcional: use recomendações de papéis para diminuir com segurança o escopo das permissões da conta de serviço padrão do Compute Engine.

     Essa conta recebe automaticamente o papel de editor (roles/editor), que tem muitas permissões. No entanto, não recomendamos usar esse papel nas configurações de produção.

     Observação: para proteger ainda mais sua organização, é possível desativar concessões automáticas de papéis a contas de serviço.

  2. Garanta que todos os usuários que implantam esses recursos possam personificar a conta de serviço padrão do Compute Engine.

     Para fornecer essa capacidade, conceda aos usuários um papel que inclua a permissão iam.serviceAccounts.actAs, como o papel de usuário da conta de serviço (roles/iam.serviceAccountUser). É possível conceder esse papel no projeto ou na conta de serviço padrão do Compute Engine. Para ver instruções, consulte Como gerenciar a personificação da conta de serviço.

     Observação: se você tiver um grande número de projetos, use o localizador de discrepâncias nas permissões (em inglês) para encontrar os usuários com permissão para implantar recursos, mas que não podem personificar a conta de serviço padrão do Compute Engine.

  3. Ative as seguintes restrições na política da organização para fazer verificações de permissão da conta de serviço ao anexar contas de serviço aos recursos:

     • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
     • constraints/dataproc.enforceComputeDefaultServiceAccountCheck

  4. Opcional: use o aplicador de políticas booleanas da organização (em inglês) para confirmar que as restrições na política da organização estão sendo aplicadas em todos os seus projetos.