Como entender as contas de serviço

Contexto

Uma conta de serviço é um tipo especial de Conta do Google destinada a representar um usuário não humano que precisa ser autenticado e autorizado a acessar dados nas APIs do Google.

Normalmente, as contas de serviço são usadas em cenários como:

  • execução de cargas de trabalho em máquinas virtuais (VMs);
  • execução de cargas de trabalho em estações de trabalho ou data centers locais que chamam as APIs do Google;
  • execução de cargas de trabalho que não estão vinculadas ao ciclo de vida de um usuário humano.

Seu aplicativo aceita a identidade da conta de serviço para chamar as APIs do Google para que os usuários não fiquem diretamente envolvidos.

Como gerenciar contas de serviço

Após verificar se uma conta de serviço é necessária, responda às seguintes perguntas para entender como usá-la:

  • Quais recursos uma conta de serviço pode acessar?
  • Quais permissões são necessárias na conta de serviço?
  • Onde estará o código que assume a identidade da conta de serviço em execução - no Google Cloud ou no local?

Use o fluxograma abaixo e descubra as respostas para essas perguntas:

Fluxograma da conta de serviço

As contas de serviço podem ser consideradas como recurso e identidade.

Ao considerar a conta de serviço como identidade, você tem como conceder um papel a uma conta de serviço, permitindo que ela acesse um recurso, como um projeto.

Ao considerar uma conta de serviço como recurso, você tem como conceder papéis a outros usuários para acessar ou gerenciar essa conta de serviço.

Como conceder acesso a contas de serviço

O processo para permitir o acesso de uma conta de serviço a um recurso é semelhante ao de qualquer outra identidade. Por exemplo, você tem um aplicativo em execução no Compute Engine e quer que ele tenha permissão apenas para criar objetos no Cloud Storage. Nesse caso, crie uma conta de serviço para esse aplicativo e conceda o papel Criador de objetos do Storage. Esse exemplo está ilustrado no diagrama abaixo:

Fluxograma da conta de serviço

Saiba mais sobre como conceder papéis a todos os tipos de membros, incluindo contas de serviço.

Como controlar as contas de serviço

Com o tempo e à medida que mais contas de serviços são criadas, pode ficar difícil manter o controle sobre o uso e a finalidade de cada uma delas.

O nome de exibição é uma boa maneira de conseguir informações extras sobre a conta de serviço como, por exemplo, finalidade ou contato. Ao criar novas contas, preencha esse nome. Para contas de serviço atuais, use o método serviceAccounts.update() para modificar o nome de exibição.

Como identificar contas de serviço não utilizadas

As contas de serviço não usadas criam um risco de segurança desnecessário. Portanto, recomendamos desativar as contas de serviço não usadas e excluir as contas de serviço quando você tiver certeza de que não precisa mais delas. Use os métodos a seguir para identificar as contas de serviço não usadas:

Como excluir e recriar contas de serviço

É possível excluir uma conta de serviço e criar uma nova com o mesmo nome.

Quando você exclui uma conta de serviço, as respectivas vinculações de papéis não são removidas imediatamente. Em vez disso, as vinculações de papéis listam a conta de serviço com o prefixo deleted:. Por exemplo, consulte Políticas com membros excluídos.

Se você criar uma nova conta de serviço com o mesmo nome de uma recém-excluída, as vinculações antigas talvez ainda existam. No entanto, elas não se aplicarão à nova conta de serviço, mesmo que as duas contas tenham o mesmo endereço de e-mail. Esse comportamento ocorre porque as contas de serviço recebem um ID exclusivo no gerenciamento de identidade e acesso (IAM) na criação. Internamente, todas as vinculações de papéis são concedidas usando esses IDs, e não o endereço de e-mail da conta de serviço. Portanto, as associações de papéis em uma conta de serviço excluída não se aplicam a uma nova conta com o mesmo endereço de e-mail.

Da mesma forma, se você anexar uma conta de serviço a um recurso, excluir a conta de serviço e criar uma nova com o mesmo nome, a nova conta de serviço não serão anexados ao recurso.

Para evitar esse comportamento inesperado, avalie a possibilidade de usar um nome novo e exclusivo para cada conta de serviço. Além disso, se você excluir acidentalmente uma conta de serviço, tente cancelar a exclusão em vez de criar uma nova conta de serviço.

Se não for possível cancelar a exclusão da conta de serviço original, e você precisar criar uma nova conta de serviço com o mesmo nome e os mesmos papéis, conceda os papéis a essa nova conta. Para detalhes, consulte Políticas com membros excluídos.

Se você também precisar que a nova conta de serviço seja anexada aos mesmos recursos da conta de serviço original, siga um destes procedimentos:

Permissões para contas de serviço

Nesta seção, descrevemos cenários comuns de permissões concedidas a contas de serviço ou contas de usuário com permissões para personificar contas de serviço:

Como conceder o mínimo de permissões a contas de serviço

Assim como em todos os tipos de membros, conceda à conta de serviço o conjunto mínimo de permissões necessárias para atingir a meta. Saiba mais sobre como conceder papéis a todos os tipos de membros, incluindo contas de serviço.

Ao conceder o acesso para uma conta de serviço aos usuários, lembre-se de que eles têm permissão para acessar todos os recursos dessa conta. Portanto, é importante configurar as permissões de suas contas de serviço com cuidado, ou seja, ser rigoroso em relação a quem da equipe pode atuar como (ou personificar) uma conta de serviço. Tenha muito cuidado ao permitir que os usuários personifiquem contas de serviço altamente privilegiadas, como as contas de serviço padrão do Compute Engine e do App Engine.

Os usuários com papéis do IAM que atualizam instâncias do App Engine e do Compute Engine, como Implantador do App Engine ou Administrador de instâncias do Compute, executam o código com eficiência, assim como as contas de serviço usadas para executar essas instâncias. Além disso, eles recebem acesso indiretamente aos mesmos recursos que essas contas. Da mesma maneira, o acesso do SSH a uma instância do Compute Engine também permite a execução do código como essa instância.

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 curta duração 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.serviceAccountAdmin (Administrador 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.

Como gerenciar chaves de contas de serviço

Há dois tipos de chaves de contas de serviço:

  • Chaves gerenciadas pelo Google Cloud. Essas chaves são usadas por serviços do Google Cloud, como o App Engine e o Compute Engine. Elas não podem ser transferidas por download, são trocadas automaticamente e usadas para assinatura por no máximo duas semanas. O processo de troca é baseado em probabilidades, e o uso da nova chave aumentará ou diminuirá a duração dela gradualmente. Recomendamos armazenar em cache o conjunto de chaves públicas de uma conta de serviço por no máximo 24 horas para garantir que você sempre tenha acesso ao conjunto de chaves atual.

  • Chaves gerenciadas pelo usuário. Os usuários criam, fazem o download e gerenciam essas chaves. Uma vez excluídas da conta de serviço, elas não podem mais ser usadas para autenticação.

No caso de chaves gerenciadas pelo usuário, verifique se você tem processos no local para atender aos requisitos de gerenciamento de chaves, como, por exemplo:

  • Armazenamento de chaves
  • Distribuição de chaves
  • Revogação de chaves
  • Troca de chaves
  • Proteção de chaves contra usuários não autorizados
  • Recuperação de chaves

Qualquer pessoa que tenha acesso a uma chave privada válida para uma conta de serviço poderá acessar recursos por meio da conta de serviço. O ciclo de vida do acesso da chave à conta de serviço (e, portanto, os dados a que a conta de serviço tem acesso) independe do ciclo de vida do usuário que fez o download da chave.

Não é recomendável que os desenvolvedores verifiquem as chaves no código-fonte nem que as deixem no diretório de downloads da estação de trabalho.

Para melhorar a segurança das chaves, siga as orientações abaixo:

Como usar as contas de serviço com o Compute Engine

As instâncias do Compute Engine precisam ser executadas como contas de serviço para terem acesso a outros recursos do Google Cloud. Para garantir a segurança das instâncias do Compute Engine, pense no seguinte:

  • É possível criar VMs no mesmo projeto com diferentes contas de serviço. Para alterar a conta de serviço de uma VM após sua criação, use o método instances.setServiceAccount.

  • Conceda papéis de IAM a contas de serviço para definir o que pode ser acessado por elas. Em muitos casos, os escopos não são mais necessários. Com isso, é possível modificar as permissões da conta de serviço de uma VM sem recriar a instância.

  • As instâncias dependem das contas de serviço para acessar os recursos do Google Cloud. Por isso, evite excluí-las enquanto estiverem sendo usadas pelas instâncias. Se as contas forem excluídas, podem ocorrer falhas nas operações das instâncias.

Práticas recomendadas

  • Determine quem pode atuar como conta de serviço. Os usuários com papéis de Usuários de contas de serviço na conta de serviço têm acesso indireto a todos os recursos da conta. Portanto, tenha cuidado ao conceder o papel serviceAccountUser a um usuário.

  • Conceda somente o conjunto mínimo de permissões exigidas à conta de serviço para atingir a meta. Saiba mais sobre como conceder papéis a todos os tipos de membros, incluindo contas de serviço.

  • Crie contas para cada serviço apenas com as permissões necessárias.

  • Use o nome de exibição de uma conta de serviço para manter o controle dela. Ao criá-la, preencha o nome de exibição com a finalidade dela.

  • Defina uma convenção de nomenclatura para as contas de serviço.

  • Implemente processos para automatizar o revezamento de chaves de contas de serviço gerenciadas por usuários.

  • Use a API da conta de serviço do IAM para implementar o revezamento de chave.

  • Faça a auditoria de contas de serviço e chaves usando o método serviceAccount.keys.list() ou a página Visualizador de registros no console.

  • Não exclua contas de serviço que estejam em uso por instâncias em execução no App Engine ou no Compute Engine, a menos que você queira que esses aplicativos percam o acesso à conta de serviço.