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 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.
Dataflow
Dataproc

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 o recomendador do IAM 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.

  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.

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

  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 Cloud, acesse a página Ambientes do Composer.

      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:

  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.

  4. Ative a restrição constraints/composer.enforceServiceAccountActAsCheck 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 ambientes.

  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:

    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:

    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
    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 o recomendador do IAM 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.

    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.

    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.