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:
- Para saber como permitir que um usuário gerencie ou represente uma única conta de serviço, consulte Gerenciar o acesso a contas de serviço.
- Para saber como permitir que um usuário gerencie ou represente todas as contas de serviço no seu projeto, consulte Gerenciar o acesso a projetos, pastas e organizações.
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