Quando cria determinados Google Cloud recursos, tem a opção de anexar uma conta de serviço. A conta de serviço anexada funciona como a identidade de quaisquer tarefas em execução no recurso, o que permite que as tarefas se autentiquem nas Google Cloud APIs.
Para a maioria dos Google Cloud serviços, os utilizadores precisam de autorização para se fazerem passar por uma conta de serviço para anexar essa conta de serviço a um recurso.
Isto significa que o utilizador precisa da autorização iam.serviceAccounts.actAs
na conta de serviço.
No entanto, no passado, determinados serviços permitiam que os utilizadores associassem contas de serviço a recursos, mesmo que não tivessem autorização para se fazerem passar pelas contas de serviço. Esta configuração pode ter permitido que os utilizadores destes serviços obtivessem autorizações elevadas e não óbvias.
A tabela seguinte indica os serviços que tinham esta configuração, juntamente com o comportamento antigo de cada serviço:
Serviço | Comportamento antigo |
---|---|
App Engine | Os utilizadores podiam implementar aplicações do App Engine, que usam a identidade da conta de serviço predefinida do App Engine, mesmo que não tivessem autorização para se fazerem passar pela conta de serviço predefinida do App Engine. |
Cloud Composer | Os utilizadores podiam anexar qualquer conta de serviço no projeto a um ambiente do Cloud Composer, mesmo que não tivessem autorização para se fazerem passar por qualquer uma das contas de serviço do projeto. |
|
Os utilizadores podiam anexar a conta de serviço predefinida do Compute Engine a recursos, mesmo que não tivessem autorização para se fazerem passar pela conta de serviço predefinida. |
Agora, exigimos que estes serviços verifiquem se os utilizadores têm autorização para se fazerem passar por contas de serviço quando associam as contas de serviço a recursos. No entanto, o comportamento antigo ainda existe para os seguintes tipos de organizações:
- Organizações com utilizadores que têm autorização para implementar aplicações do App Engine, mas não têm autorização para se fazerem passar pela conta de serviço predefinida do App Engine.
- Organizações com utilizadores que têm autorização para implementar ambientes do Cloud Composer, mas não têm autorização para se fazerem passar por contas de serviço.
- Organizações com utilizadores que têm autorização para implementar recursos do Cloud Data Fusion, Dataflow ou Dataproc, mas não têm autorização para se fazerem passar pela conta de serviço predefinida do Compute Engine.
Se a sua organização ainda for afetada pelo comportamento antigo, recebeu uma comunicação a explicar como desativá-lo manualmente. Também pode consultar as secções abaixo para ver instruções detalhadas.
Proteger o App Engine
Para desativar manualmente o comportamento antigo do App Engine, certifique-se de que os utilizadores têm autorização para se fazerem passar pela conta de serviço do App Engine. Em seguida, ative uma restrição da política da organização para aplicar verificações de autorizações da conta de serviço quando implementar aplicações que usam a identidade da conta de serviço predefinida do App Engine.
Opcional: use recomendações de funções para reduzir o âmbito das autorizações de forma segura para a conta de serviço predefinida do App Engine.
À conta de serviço predefinida do App Engine é concedida automaticamente a função de editor altamente permissiva (
roles/editor
). No entanto, não recomendamos a utilização de uma função tão permissiva em configurações de produção.Certifique-se de que todos os utilizadores que implementam aplicações têm a capacidade de se fazerem passar pela conta de serviço predefinida do App Engine.
Para fornecer esta capacidade, conceda aos utilizadores uma função que inclua a autorização
iam.serviceAccounts.actAs
, como a função de utilizador da conta de serviço (roles/iam.serviceAccountUser
). Pode conceder esta função no projeto ou na conta de serviço predefinida do App Engine. Para obter instruções, consulte o artigo Faça a gestão da simulação da conta de serviço.Ative a restrição da política da organização
constraints/appengine.enforceServiceAccountActAsCheck
para aplicar verificações de autorizações da conta de serviço quando implementar aplicações.Opcional: use o aplicador de políticas da organização booleanas para confirmar que a restrição da política da organização é aplicada em todos os seus projetos.
Proteger o Cloud Composer
Para desativar manualmente o comportamento antigo do Cloud Composer, certifique-se de que os utilizadores têm autorização para se fazerem passar pelas contas de serviço que associam a novos ambientes. Em seguida, ative uma restrição da política da organização para aplicar verificações de autorizações de contas de serviço quando anexar contas de serviço a ambientes.
Identifique todas as contas de serviço associadas a ambientes do Cloud Composer:
Na Google Cloud consola, aceda à página Ambientes do Composer.
Clique no nome de um ambiente.
No separador Configuração do ambiente, encontre o campo Conta de serviço e registe o nome da conta de serviço.
Repita os passos anteriores para todos os ambientes do Cloud Composer no seu projeto.
Confirme que estas contas de serviço seguem o princípio do menor privilégio:
Na Google Cloud consola, aceda à página IAM, encontre as contas de serviço e reveja as respetivas funções.
Se necessário, conceda uma função menos permissiva à conta de serviço. Pode selecionar uma função na lista de funções predefinidas do IAM, usar uma função sugerida por uma recomendação de função ou criar uma função personalizada.
Certifique-se de que todos os utilizadores que implementam ou gerem ambientes do Cloud Composer têm a capacidade de se fazer passar pelas contas de serviço que os ambientes usam.
Para conceder esta capacidade, atribua aos utilizadores uma função que inclua a autorização
iam.serviceAccounts.actAs
, como a função de utilizador da conta de serviço (roles/iam.serviceAccountUser
). Pode atribuir esta função no projeto ou numa conta de serviço individual. Para obter instruções, consulte o artigo Faça a gestão da simulação da conta de serviço.Ative a restrição da política da organização
constraints/composer.enforceServiceAccountActAsCheck
para aplicar verificações de autorizações de contas de serviço quando anexar contas de serviço a ambientes.Opcional: use o aplicador de políticas da organização booleanas para confirmar que a restrição da política da organização é aplicada em todos os seus projetos.
Proteger o Dataproc, o Dataflow e o Cloud Data Fusion
Para desativar manualmente o comportamento antigo do Dataproc, do Dataflow e do Cloud Data Fusion, certifique-se de que os utilizadores têm autorização para se fazerem passar pelas contas de serviço que associam a novos recursos. Em seguida, ative as restrições da política da organização para aplicar verificações de autorizações de contas de serviço quando anexar contas de serviço a recursos.
Siga as instruções para o tipo de conta de serviço que quer anexar a novos recursos:
Se quiser parar de anexar a conta de serviço predefinida do Compute Engine a novos recursos, siga estes passos:
Crie uma nova conta de serviço e conceda à conta de serviço as funções de que precisa para executar tarefas no recurso. Certifique-se de que segue o princípio do menor privilégio.
Para saber que funções uma conta de serviço precisa para executar tarefas em recursos do Dataproc, Dataflow e Cloud Data Fusion, consulte o seguinte:
- Requisitos da conta de serviço do Dataproc
- Requisitos da 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.
Permita que todos os utilizadores que implementam estes recursos se façam passar pela nova conta de serviço.
Para conceder esta capacidade, atribua aos utilizadores uma função que inclua a autorização
iam.serviceAccounts.actAs
, como a função de utilizador da conta de serviço (roles/iam.serviceAccountUser
). Pode atribuir esta função no projeto ou na conta de serviço. Para obter instruções, consulte o artigo Faça a gestão da simulação da conta de serviço.Ative as seguintes restrições de políticas da organização para aplicar verificações de autorizações de contas de serviço quando anexar contas de serviço a 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 autorizações para o Cloud Data Fusion.Opcional: use o aplicador de políticas da organização booleanas para confirmar que as restrições das políticas da organização são aplicadas em todos os seus projetos.
Quando implementar novos recursos, use a nova conta de serviço em vez da conta de serviço predefinida do Compute Engine.
Se quiser continuar a anexar a conta de serviço predefinida do Compute Engine a novos recursos, siga estes passos:
Opcional: use recomendações de funções para reduzir com segurança o âmbito das autorizações da conta de serviço predefinida do Compute Engine.
A conta de serviço predefinida do Compute Engine recebe automaticamente a função de editor com muitas autorizações (
roles/editor
). No entanto, não recomendamos a utilização de uma função com muitas autorizações em configurações de produção.Certifique-se de que todos os utilizadores que implementam estes recursos têm a capacidade de se fazerem passar pela conta de serviço predefinida do Compute Engine.
Para fornecer esta capacidade, conceda aos utilizadores uma função que inclua a autorização
iam.serviceAccounts.actAs
, como a função de utilizador da conta de serviço (roles/iam.serviceAccountUser
). Pode conceder esta função no projeto ou na conta de serviço predefinida do Compute Engine. Para obter instruções, consulte o artigo Faça a gestão da simulação da conta de serviço.Ative as seguintes restrições de políticas da organização para aplicar verificações de autorizações de contas de serviço quando anexar contas de serviço a recursos:
constraints/dataflow.enforceComputeDefaultServiceAccountCheck
constraints/dataproc.enforceComputeDefaultServiceAccountCheck
Opcional: use o aplicador de políticas da organização booleanas para confirmar que as restrições das políticas da organização são aplicadas em todos os seus projetos.