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

Ao criar determinados recursos do Google Cloud , você 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.
Dataform	Os usuários podiam anexar uma conta de serviço a um recurso do Dataform e criar uma invocação de fluxo de trabalho que seria executada como essa conta, mesmo que não tivessem permissão para personificá-la.

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.
Organizações com usuários que têm permissão para anexar uma conta de serviço a um recurso do Dataform e criar uma invocação de fluxo de trabalho, mas não têm permissão para personificar a conta de serviço.

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.

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

Identifique todas as contas de serviço vinculadas aos ambientes do Cloud Composer:
1. No Google Cloud console, 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.
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.
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 para encontrar os usuários com permissão para implantar ambientes do Cloud Composer, mas não para personificar contas de serviço.
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.
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.

Como proteger o Dataform

Para desativar manualmente o comportamento legado do Dataform, verifique se os usuários têm permissão para personificar as contas de serviço anexadas aos recursos do Dataform. Em seguida, ative o modo estrito de atuação como para fazer verificações de permissão da conta de serviço ao criar invocações de fluxo de trabalho.

Verifique se há problemas de permissão para evitar interrupções nos seus fluxos de trabalho. Para isso, consulte o Cloud Logging em busca de entradas específicas do Dataform que indicam que um principal (usuário ou conta de serviço) não tem a permissão iam.serviceAccounts.actAs necessária. Assim, é possível identificar e resolver proativamente qualquer discrepância de acesso. Para mais informações, consulte Verificar problemas de permissão no Cloud Logging.
Para usuários ou contas de serviço que precisam criar invocações de fluxo de trabalho, conceda a eles a permissão para personificar a conta de serviço associada ao repositório do Dataform. Para isso, conceda o papel de usuário da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço específica. Para mais informações, consulte Resolver problemas de permissão.
Se você estiver usando uma conta de serviço personalizada, conceda os seguintes papéis ao agente de serviço padrão do Dataform na conta de serviço personalizada:
- Criador do token da conta de serviço (roles/iam.serviceAccountTokenCreator): necessário para todas as operações de repositório usando uma conta de serviço personalizada.
- Usuário da conta de serviço (roles/iam.serviceAccountUser): necessário apenas se você estiver usando configurações de fluxo de trabalho para programar ou automatizar execuções. Com essa função, o agente de serviço padrão do Dataform pode executar tarefas como a conta de serviço personalizada.
Para aplicar a verificação de permissão "agir como", ative o modo estrito "agir como". Esse recurso aumenta a segurança ao verificar se qualquer usuário que cria uma invocação de fluxo de trabalho tem a permissão iam.serviceAccounts.actAs na conta de serviço efetiva.
- Para um novo repositório, o modo estrito "agir como" é ativado por padrão.
- Para um repositório atual, atualize-o definindo a flag strict_act_as_checks como true.
Para mais informações, consulte Usar o modo estrito "agir como".
Audite periodicamente seus recursos do Dataform para garantir o uso adequado da conta de serviço e a concessão de permissões. Use o Inventário de recursos do Cloud para listar todos os recursos dos tipos dataform.Repository e dataform.WorkflowConfig e inspecione o campo resource.data.serviceAccount para verificar qual conta de serviço está sendo usada. Se uma conta de serviço personalizada for usada, verifique se o agente de serviço padrão do Dataform tem os papéis Usuário da conta de serviço (roles/iam.serviceAccountUser) e Criador de token da conta de serviço (roles/iam.serviceAccountTokenCreator) nessa conta personalizada. Para mais informações, consulte Auditar configurações de contas de serviço.