Os principais podem usar contas de serviço para autenticar de algumas maneiras diferentes. Cada tipo de autenticação exige que o principal tenha permissões específicas do Identity and Access Management (IAM) na conta de serviço.
Nesta página, descrevemos os papéis que podem ser concedidos aos principais para permitir que eles personifiquem contas de serviço. Também descreve as permissões necessárias em cenários comuns.
Para saber mais sobre as diferentes maneiras de autenticar com uma conta de serviço, consulte Credenciais da conta de serviço e Representação da conta de serviço.
Papéis da conta de serviço
Nesta seção, descrevemos os papéis que permitem que os participantes se autentiquem com contas de serviço. Para saber como conceder e revogar esses papéis, consulte Gerenciar o acesso a contas de serviço.
Papel Usuário da conta de serviço
O papel Usuário da conta de serviço (roles/iam.serviceAccountUser) permite que um principal anexe uma conta de serviço a um recurso. Quando o código em execução nesse recurso precisa ser autenticado, ele pode receber credenciais para a conta de serviço anexada.
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ê precisa do papel Criador de token da conta de serviço na conta de serviço.
Papel Criador de token da conta de serviço
O papel Criador de token da conta de serviço (roles/iam.serviceAccountTokenCreator) permite que os participantes criem credenciais de curta duração para uma conta de serviço.
O papel Criador do token da conta de serviço permite criar os seguintes tipos de credenciais de curta duração:
- Tokens de acesso do OAuth 2.0, que podem ser usados para autenticar com as APIs do Google
- Tokens de ID do OpenID Connect (OIDC)
- JSON Web Tokens (JWTs) e blobs binários assinados
O papel Criador de token da conta de serviço também permite que os participantes usem a sinalização --impersonate-service-account para a CLI gcloud. Quando você usa essa sinalização, a CLI da gcloud cria automaticamente credenciais de curta duração para a conta de serviç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.
Criador do token de identidade do OpenID Connect da conta de serviço
O papel Criador do token de identidade do OpenID Connect da conta de serviço (roles/iam.serviceAccountOpenIdTokenCreator) permite que os participantes criem tokens de ID do OIDC de curta duração. Se você só precisa criar tokens de ID do OIDC, use esse papel. Se você precisar criar outros tipos de tokens, use o papel Criador de tokens da conta de serviço.
O papel inclui a permissão iam.serviceAccounts.getOpenIdToken, que permite criar um token de ID do OIDC.
Papel Usuário da identidade de carga de trabalho
O papel de usuário da Identidade da carga de trabalho (roles/iam.workloadIdentityUser) permite que os principais representem as contas de serviço das 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, é preciso ter permissões para
criar esse recurso e permissão para anexar a conta de serviço aos recursos.
Permissão para anexar contas de serviço a recursos fornecidos por qualquer papel que inclua a permissão iam.serviceAccounts.actAs. Por exemplo, o papel de usuário da conta de serviço (roles/iam.serviceAccountUser).
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
Permissões:
iam.serviceAccounts.getAccessTokeniam.serviceAccounts.signBlobiam.serviceAccounts.signJwtiam.serviceAccounts.implicitDelegation
Papéis:
roles/iam.serviceAccountTokenCreator(Criador do token da conta de serviço)
Depois de receber as permissões necessárias, um usuário ou outra conta de serviço pode representar a conta de serviço em alguns cenários comuns.
Primeiro, o usuário pode fazer a autenticação como a conta de serviço. Por exemplo, eles podem receber credenciais de curta duração para a conta de serviço usando a permissão iam.serviceAccounts.getAccessToken e chamando o método
generateAccessToken(). Também é possível usar a
flag --impersonate-service-account da
CLI gcloud para representar a conta de serviço. Quando um usuário
se autentica como uma conta de serviço, ele pode emitir comandos para
o Google Cloud e acessar todos os recursos aos quais a conta de serviço tem
acesso.
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 representar a conta de serviço sem recuperar uma
credencial para ela. 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.serviceAccountOpenIdTokenCreator(Criador do token de identidade do OpenID Connect 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