Papéis para gerenciar e representar contas de serviço

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

As contas de serviço são identidades e recursos. Como as contas de serviço são recursos que aceitam políticas de permissão, é possível permitir que outros principais acessem contas de serviço concedendo papéis em uma conta de serviço.

Nesta página, listamos os papéis que você pode conceder aos principais para permitir que eles criem, gerenciem ou representem contas de serviço. Gerenciar contas de serviço envolve ações como visualizar, atualizar, excluir, desativar, ativar e listar contas de serviço, bem como gerenciar as políticas do IAM. Representar contas de serviço é quando um usuário usa credenciais de curta duração para autenticar como uma conta de serviço. Normalmente, esse método é usado para ter acesso temporário. Para saber mais sobre a representação de uma conta de serviço, consulte Representação da conta de serviço.

Nesta página, também descrevemos as permissões necessárias para trabalhar com contas de serviço em determinados cenários comuns.

Papéis da conta de serviço

É possível conceder os papéis a seguir aos principais para permitir que eles gerenciem ou representem contas de serviço.

Para saber como conceder esses papéis a um usuário, consulte:

Papel Usuário da conta de serviço

O papel de usuário da conta de serviço (roles/iam.serviceAccountUser) inclui a permissão iam.serviceAccounts.actAs, que permite que os principais acessem indiretamente todos os recursos que a conta de serviço pode acessar. Por exemplo, se um principal tiver o papel de Usuário da conta de serviço em uma conta de serviço, e a conta de serviço tiver o papel de Administrador do Cloud SQL (roles/cloudsql.admin) no projeto, o principal poderá representar a conta de serviço para criar um instância do Cloud SQL.

Esse papel também permite que os principais anexem uma conta de serviço a um recurso.

Esse papel não permite que os principais criem credenciais de curta duração para contas de serviço nem usem a sinalização --impersonate-service-account da CLI do Google Cloud. Para concluir essas tarefas, você também precisa do papel "Criador de token da conta de serviço".

Papel Criador de token da conta de serviço

Com papel, os participantes representam as contas de serviço para fazer o seguinte:

  • criar tokens de acesso do OAuth 2.0, que podem ser usados para autenticar com as APIs do Google;
  • criar tokens de ID do OpenID Connect (OIDC);
  • assinar JSON Web Tokens (JWTs, na sigla em inglês) e blobs binários para que possam ser usados na autenticação.

Consulte os detalhes em Como criar credenciais da conta de serviço de curta duração.

As permissões do papel incluem o seguinte:

  • iam.serviceAccounts.getAccessToken: permite criar tokens de acesso do OAuth 2.0.
  • iam.serviceAccounts.getOpenIdToken: permite criar tokens de ID do OpenID Connect (OIDC).
  • iam.serviceAccounts.implicitDelegation: permite que as contas de serviço recebam tokens em uma cadeia de delegação.
  • iam.serviceAccounts.signBlob: permite a assinatura de blobs binários.
  • iam.serviceAccounts.signJwt: permite a assinatura de JWTs.

Papel Usuário da identidade de carga de trabalho

Esse papel permite que os participantes representem contas de serviço de cargas de trabalho do GKE.

As permissões do papel incluem o seguinte:

  • iam.serviceAccounts.getAccessToken: permite criar tokens de acesso do OAuth 2.0.
  • iam.serviceAccounts.getOpenIdToken: permite criar tokens de ID do OpenID Connect (OIDC).

Permissões de conta de serviço para cenários comuns

As contas de serviço podem ser usadas em muitos cenários diferentes, e cada uma delas exige permissões específicas. Nesta seção, descrevemos cenários comuns e as permissões necessárias.

Como anexar contas de serviço a recursos

Se você quiser iniciar um job de longa duração que seja autenticado como uma conta de serviço, será necessário anexar uma conta de serviço ao recurso que executará o job.

Permissões:

  • Permissões para criar o recurso
  • iam.serviceAccounts.actAs

Para procurar papéis que incluam essas permissões, procure a permissão na lista de papéis.

Há vários recursos diferentes do Google Cloud que podem executar jobs de longa duração como contas de serviço. Veja alguns exemplos desses recursos:

  • VMs do Compute Engine
  • Aplicativos do App Engine
  • Cloud Functions

Ao criar esses recursos, você tem a opção de anexar uma conta de serviço. Essa conta de serviço atua como a identidade do recurso.

Para criar um recurso e anexar uma conta de serviço, você precisa de permissões para criar esse recurso e permissão para personificar a conta de serviço que você anexará ao recurso. A permissão para personificar a conta de serviço é fornecida por qualquer papel que inclua a permissão iam.serviceAccounts.actAs.

Depois de criar o recurso e anexar uma conta de serviço a ele, será possível iniciar um job de longa duração no recurso. O job é executado como a conta de serviço anexada ao recurso e a usa para autorizar solicitações às APIs do Google Cloud.

Para saber mais sobre como anexar contas de serviço a recursos, consulte Como anexar uma conta de serviço a um recurso.

Como personificar uma conta de serviço diretamente

Permissões:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccounts.implicitDelegation

Papéis:

  • roles/iam.serviceAccountTokenCreator (Criador do token da conta de serviço)

Uma vez concedidas as permissões exigidas, um usuário (ou serviço) pode personificar diretamente (ou declarar) a identidade de uma conta de serviço em alguns cenários comuns.

Primeiro, o usuário pode conseguir credenciais de curto prazo para a conta de serviço usando a permissão iam.serviceAccounts.getAccessToken e chamando o método generateAccessToken(). Ao usar credenciais de curto prazo, um usuário pode emitir comandos para o Google Cloud e acessar todos os recursos aos quais a conta de serviço tem acesso. Por exemplo, esse fluxo permite que um usuário use a sinalização gcloud --impersonate-service-account para personificar a conta de serviço sem exigir o uso de uma chave de conta de serviço externa recebida por download.

Depois, o usuário pode receber artefatos assinados pela chave privada gerenciada pelo Google da conta de serviço usando a permissão iam.serviceAccounts.signBlob e chamando o método signBlob() ou signJwt(). A chave privada gerenciada pelo Google sempre é mantida em garantia e nunca exposta diretamente. signBlob() permite a assinatura de payloads arbitrários, como URLs assinados do Cloud Storage, enquanto signJwt() só permite a assinatura de JWTs bem formados.

Por fim, o usuário pode personificar (ou declarar) a conta de serviço sem precisar recuperar uma credencial para a conta de serviço. Trata-se de um caso de uso avançado, compatível apenas com acesso programático usando o método generateAccessToken(). Em cenários com pelo menos três contas de serviço, sendo elas A, B e C: a conta de serviço A poderá receber um token de acesso para a conta de serviço C se a conta de serviço A receber a permissão iam.serviceAccounts.implicitDelegation em B e B receber a permissão iam.serviceAccounts.getAccessToken em C.

Como gerar tokens de ID do OpenID Connect (OIDC)

Permissões:

  • iam.serviceAccounts.getOpenIdToken

Papéis:

  • roles/iam.serviceAccountTokenCreator (Criador do token da conta de serviço)

Um usuário (ou serviço) pode gerar um token JWT compatível com OpenID Connect (OIDC) assinado pelo provedor OIDC do Google (accounts.google.com) que representa a identidade da conta de serviço usando a permissão iam.serviceAccounts.getOpenIdToken.

Esses tokens não são aceitos diretamente pela maioria das APIs do Google sem que sua organização implante outra federação de identidade para conceder acesso ao Google. Há algumas exceções, como o Identity-Aware Proxy, que permite o acesso baseado em OIDC a aplicativos executados pelo usuário.

Como gerar chaves particulares externas

Permissões:

  • iam.serviceAccountKeys.create

Papéis:

  • roles/editor (Editor)
  • roles/iam.serviceAccountKeyAdmin (Administrador da chave da conta de serviço)

Um usuário ou serviço pode gerar material de chave privada externa (RSA) a ser usado para autenticar-se diretamente no Google como a conta de serviço. Esse material de chave pode, então, ser usado com bibliotecas Application Default Credentials (ADC) ou com o comando gcloud auth activate-service-account. Qualquer pessoa que tiver acesso ao material da chave terá acesso total a todos os recursos a que a conta de serviço tem acesso. Esse material de chave privada deve ser tratado com a maior preocupação e deve ser considerado menos seguro quanto maior ele for. Portanto, o revezamento de material de chave privada é essencial para manter a segurança.

Práticas recomendadas para conceder papéis em contas de serviço

Nos cenários em que uma conta de serviço recebeu permissões para executar operações altamente privilegiadas, tenha cuidado ao conceder a um usuário dela o papel de Usuário de conta de serviço.

As contas de serviço representam a segurança em nível de serviço. A segurança do serviço é determinada pelas pessoas que têm papéis do IAM para gerenciar e usar as contas de serviço, e pessoas que têm chaves externas privadas para essas contas de serviço. As práticas recomendadas para garantir a segurança incluem o seguinte:

  • Use a API do IAM para auditar as contas de serviço, as chaves e as políticas de permissão nessas contas de serviço.
  • Se as contas de serviço não precisam de chaves de conta de serviço, desative ou exclua-as.
  • Se os usuários não precisarem de permissão para gerenciar ou usar contas de serviço, remova eles da política de permissão aplicável.
  • Verifique se as contas de serviço têm o mínimo de permissões possível. Use contas de serviço padrão com cuidado, porque eles recebem automaticamente o papel de editor (roles/editor) no projeto.

Para saber mais sobre as práticas recomendadas, consulte Práticas recomendadas para trabalhar com contas de serviço.

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Comece a usar gratuitamente