Práticas recomendadas para usar e gerenciar contas de serviço

As contas de serviço representam usuários não humanos. Elas são destinadas a cenários em que uma carga de trabalho, como um aplicativo personalizado, precisa acessar recursos ou executar ações sem o envolvimento do usuário final.

As contas de serviço diferem das contas de usuário normais de várias maneiras:

  • Elas não têm senha e não podem ser usadas para fazer login pelo navegador.
  • Elas são criadas e gerenciadas como um recurso que pertence a um projeto do Google Cloud. Por outro lado, os usuários são gerenciados em uma conta do Cloud Identity ou do Google Workspace.
  • Elas são específicas do Google Cloud. Por outro lado, os usuários gerenciados no Cloud Identity ou no Google Workspace trabalham em uma grande variedade de produtos e serviços do Google.

Este guia apresenta as práticas recomendadas para gerenciar, usar e proteger contas de serviço.

Escolher quando usar contas de serviço

As contas de serviço podem ser usadas para muitos fins, mas nem sempre eles são a melhor escolha. A seção a seguir fornece orientações sobre quando usar contas de serviço e quando evitá-las.

Use contas de serviço para cenários autônomos

Nem todos os aplicativos interagem com os usuários humanos. Um aplicativo pode estar em execução no segundo plano autônomo. Isso inclui jobs em lote, processos de worker que enviam mensagens lidas de uma fila ou um agente de monitoramento de recursos.

Sempre que um aplicativo autônomo precisar acessar um recurso, como um bucket do Cloud Storage, ele precisará agir em seu próprio nome e não em nome de qualquer usuário final. Para agir em seu próprio nome, o aplicativo precisa de sua própria identidade que não esteja relacionada a nenhuma identidade de usuário final.

Para fornecer ao aplicativo sua própria identidade, crie uma conta de serviço para ele e conceda à conta de serviço acesso aos recursos que o aplicativo precisa acessar. Ao permitir que um aplicativo use a própria conta de serviço, você ajuda a garantir que o aplicativo funcione sem a interação do usuário. Além disso, você também garante que todos os acessos de recursos iniciados pelo aplicativo possam ser atribuídos de volta ao mesmo aplicativo.

Use contas de serviço para fazer uma transição entre principais

Um aplicativo que interage com os usuários finais pode usar o Login do Google para autenticar esses usuários, mas ele não é obrigado a fazer isso. Em vez disso, um aplicativo pode depender de provedor de identidade de terceiros ou implementar um esquema de autenticação personalizado para autenticar os usuários.

Se um aplicativo usar identidades de terceiros ou personalizadas e precisar acessar um recurso, como um conjunto de dados do BigQuery ou um bucket do Cloud Storage, ele precisará executar uma transição entre principais. Como as APIs do Google Cloud não reconhecem identidades de terceiros ou personalizadas, o aplicativo não pode propagar a identidade do usuário final para o BigQuery ou o Cloud Storage. Em vez disso, o aplicativo precisa executar o acesso usando uma identidade diferente do Google.

Para permitir que um aplicativo faça uma transição entre principais, crie uma conta de serviço para ele e conceda a ela acesso aos recursos que o aplicativo precisa acessar. Sempre que o aplicativo precisar acessar um recurso do Google Cloud, primeiro verifique se ele autenticou o usuário final. Em seguida, permita que ele use a conta de serviço para acessar o recurso.

As transições entre principais podem limitar a utilidade dos registros de auditoria do Cloud de recursos afetados do Google Cloud: como o aplicativo usa uma conta de serviço para acessar recursos, os registros de auditoria do Cloud podem não indicar claramente se uma ação foi ou não realizada em nome de determinado usuário final. Para ajudar a garantir o não repúdio, estenda seu aplicativo para gravar um registro de log personalizado sempre que ocorrer uma transição entre os principais. Dessa forma, é possível rastrear qual usuário final acionou um acesso a recursos.

Um aplicativo pode exigir acesso a dados confidenciais ou pessoais do usuário. Alguns exemplos são: caixa de e-mails ou agenda de um usuário, documentos armazenados no Drive ou um conjunto de dados do BigQuery que contém dados confidenciais.

O uso de uma conta de serviço para acessar dados do usuário pode ser apropriado se o aplicativo realizar tarefas autônomas em segundo plano, como indexação ou verificação de perda de dados (DLP, na sigla em inglês), ou se o usuário final não tiver sido autenticado com uma identidade do Google. Em todos os outros cenários em que um aplicativo age em nome de um usuário final, é melhor evitar o uso de contas de serviço.

Em vez de usar uma conta de serviço para acessar dados do usuário (possivelmente realizando uma transição principal), use o fluxo de consentimento do OAuth para solicitar o consentimento do usuário final. Em seguida, permita que o aplicativo aja com a identidade do usuário final. Usar OAuth em vez de uma conta de serviço ajuda a garantir que:

  • Os usuários possam analisar a quais recursos estão prestes a conceder acesso ao aplicativo e possam expressar ou negar explicitamente o consentimento deles.
  • Os usuários possam revogar o consentimento na página Minha conta a qualquer momento.
  • Você não precise de uma conta de serviço que tenha acesso irrestrito aos dados de todos os usuários.

Ao permitir que o aplicativo use as credenciais de usuário final, você adia as verificações de permissão nas APIs do Google Cloud. Essa abordagem limita o risco de exposição acidental de dados que o usuário não deve ter permissão de acesso devido a um erro de codificação (problema de confused deputy).

Não use contas de serviço durante o desenvolvimento

Durante seu trabalho diário, você pode usar ferramentas como a ferramenta de linha de comando gcloud, gsutil ou terraform. Não use uma conta de serviço para executar essas ferramentas. Em vez disso, permita que elas usem suas credenciais primeiro executando gcloud auth login (para a ferramenta gcloud e gsutil) ou gcloud auth application-default login (para terraform e outras ferramentas de terceiros).

É possível usar uma abordagem semelhante para desenvolver e depurar aplicativos que você planeja implantar no Google Cloud. Depois de implantado, o aplicativo pode exigir uma conta de serviço. Porém, se você executá-lo na estação de trabalho local, poderá permitir que ele use suas credenciais pessoais.

Para ajudar a garantir que o aplicativo aceita credenciais pessoais e de conta de serviço, use as bibliotecas de cliente do Cloud para encontrar credenciais automaticamente.

Como usar contas de serviço

Os usuários costumam se autenticar no Google Cloud usando um nome de usuário e uma senha ou o logon único (SSO, na sigla em inglês). As contas de serviço não têm uma senha e não podem usar o SSO. Elas aceitam um conjunto diferente de métodos de autenticação. Na seção a seguir, apresentamos as práticas recomendadas para selecionar um método de autenticação.

Como usar contas de serviço

Use contas de serviço anexadas quando possível

Para permitir que um aplicativo implantado no Google Cloud use uma conta de serviço, anexe a conta de serviço ao recurso de computação subjacente. Ao anexar a conta de serviço, você permite que o aplicativo consiga tokens para a conta de serviço e use-os para acessar as APIs e os recursos do Google Cloud.

Para receber tokens de acesso no aplicativo, use as bibliotecas de cliente, se possível. As bibliotecas de cliente detectam automaticamente se o aplicativo está sendo executado em um recurso de computação com uma conta de serviço anexada.

Em situações em que o uso das bibliotecas de cliente não é prático, ajuste seu aplicativo para receber tokens de maneira programática a partir do servidor de metadados. Os recursos de computação compatíveis com o acesso ao servidor de metadados incluem:

Para ver a lista completa dos recursos de computação que permitem anexar uma conta de serviço, consulte Como gerenciar a personificação da conta de serviço.

Use a Identidade da carga de trabalho para anexar contas de serviço aos pods do Kubernetes

Se você usa o Google Kubernetes Engine, pode ser que esteja executando uma combinação de diferentes aplicativos em um único cluster do GKE. Os aplicativos individuais provavelmente serão diferentes nos recursos e nas APIs que precisam acessar.

Se você anexar uma conta de serviço a um cluster do GKE ou a um dos pools de nós, por padrão, todos os pods em execução no cluster ou no pool de nós poderão personificar a conta de serviço. O compartilhamento de uma única conta de serviço em diferentes aplicativos dificulta a atribuição do conjunto correto de privilégios à conta de serviço:

  • Se você só conceder acesso a recursos que todos os aplicativos exigem, alguns aplicativos podem não funcionar por não ter acesso a determinados recursos.
  • Se você conceder acesso a todos os recursos de que um determinado aplicativo precisa, você poderá estar concedendo acessos em excesso.

Uma abordagem melhor para gerenciar o acesso a recursos em um ambiente do GKE é usar a Identidade da carga de trabalho:

  1. Não anexe contas de serviço a clusters do GKE ou a pools de nós.
  2. Crie uma conta de serviço dedicada para cada pod do Kubernetes que requer acesso a APIs ou recursos do Google.
  3. Crie uma conta de serviço do Kubernetes para cada pod do Kubernetes que precise de acesso a APIs ou recursos do Google e anexe-a ao pod.
  4. Use a Identidade da carga de trabalho para criar um mapeamento entre as contas de serviço e as contas de serviço do Kubernetes correspondentes.

Use a federação de identidade de carga de trabalho para permitir que aplicativos em execução no local ou em outros provedores de nuvem usem uma conta de serviço

Se o aplicativo estiver em execução no local ou em outro provedor de nuvem, não será possível anexar uma conta de serviço aos recursos de computação subjacentes. No entanto, o aplicativo pode ter acesso a credenciais específicas do ambiente, como:

  • Credenciais temporárias da AWS
  • Tokens de acesso do Azure Active Directory
  • Tokens de acesso OpenID ou tokens de ID emitidos por um provedor de identidade local como o Active Directory Federation Services (AD FS) ou o KeyCloak

Se seu aplicativo tiver acesso a uma dessas credenciais e precisar de acesso a APIs ou recursos do Google Cloud, use a federação de identidade da carga de trabalho.

A federação de identidade de carga de trabalho permite que você crie uma relação de confiança unidirecional entre um projeto do Google Cloud e um provedor de identidade externo. Depois de estabelecer a confiança, os aplicativos poderão usar credenciais emitidas pelo provedor de identidade confiável para personificar uma conta de serviço seguindo um processo de três etapas:

  1. Consiga uma credencial pelo provedor de identidade confiável, por exemplo, um token de ID do OpenID Connect.
  2. Use a API Security Token Service (STS) para trocar a credencial por um token do Google STS de curta duração.
  3. Use o token STS para se autenticar na API IAM Service Account Credentials e receba tokens de acesso de curta duração do Google para uma conta de serviço.

Ao usar a federação de identidade de carga de trabalho, você pode permitir que os aplicativos usem os mecanismos de autenticação fornecidos pelo ambiente externo e evita a necessidade de armazenar e gerenciar chaves de conta de serviço.

Use a API IAM Credentials para implantar credenciais

Alguns aplicativos só exigem acesso a determinados recursos em momentos específicos ou em circunstâncias específicas. Exemplo:

  • Um aplicativo pode exigir acesso aos dados de configuração durante a inicialização, mas pode não exigir esse acesso depois que for inicializado.
  • Um aplicativo supervisor pode iniciar periodicamente jobs em segundo plano em que cada job tem requisitos de acesso diferentes.

Nessas situações, usar uma única conta de serviço e conceder a ela acesso a todos os recursos vai contra o princípio de privilégio mínimo: é provável que, a qualquer momento, o aplicativo tenha acesso a mais recursos do que realmente precisa.

Para garantir que as diferentes partes do aplicativo só tenham acesso aos recursos de que precisam, use a API IAM Credentials para monitorar credenciais de curta duração:

  • Crie contas de serviço dedicadas para cada parte do aplicativo ou caso de uso e conceda à conta de serviço acesso apenas aos recursos necessários.
  • Crie outra conta de serviço que funcione como o supervisor. Conceda à conta de serviço do supervisor o papel de Criador de token da conta de serviço nas outras contas de serviço para que ele possa solicitar tokens de acesso de curta duração para essas contas de serviço.
  • Divida seu aplicativo para que uma parte do aplicativo sirva como agente de token e permita que somente essa parte do aplicativo use as contas de serviço do supervisor.
  • Use o agente de token para emitir contas de serviço de curta duração para as outras partes do aplicativo.

Use as chaves da conta de serviço se não houver uma alternativa viável

Às vezes, é possível se deparar com uma situação em que não é possível anexar uma conta de serviço e usar a Identidade da carga de trabalho ou a federação de identidade da carga de trabalho também não são opções viáveis. Por exemplo, um dos seus aplicativos locais pode precisar de acesso aos recursos do Google Cloud. No entanto, seu provedor de identidade local não é compatível com o OpenID Connect e, portanto, não pode ser usado na federação de identidades de carga de trabalho.

Em situações em que outras abordagens de autenticação não são viáveis, crie uma chave de conta de serviço para o aplicativo. A chave da conta de serviço permite que um aplicativo faça a autenticação como uma conta de serviço, semelhante a como um usuário pode se autenticar com um nome de usuário e uma senha. As chaves da conta de serviço são um tipo de secret e precisam ser protegidas contra acesso não autorizado. É melhor armazená-las em um local seguro, como um cofre de chaves, e rotacioná-las com frequência.

Como gerenciar contas de serviço

As contas de serviço são diferentes das contas normais de usuário, não apenas na forma como são usadas, mas também na forma como são gerenciadas. As seções a seguir fornecem práticas recomendadas para o gerenciamento de contas de serviço.

Gerencie contas de serviço como recursos

As contas normais de usuário geralmente são gerenciadas de acordo com os processos joiner-mover-leaver de uma organização: quando um funcionário entra para a empresa, uma nova conta de usuário é criada para ele. Quando eles migram para outro departamento, a conta de usuário é atualizada. E quando ele sai da empresa, a conta de usuário é suspensa ou excluída.

Por outro lado, as contas de serviço não são associadas a nenhum funcionário específico. Pense nas contas de serviço como recursos pertencentes, ou que fazem parte, a outro recurso, como uma determinada instância de VM ou um aplicativo.

Para gerenciar contas de serviço de maneira eficaz, não considere as contas de serviço isoladamente. Considere-as no contexto do recurso a que estão associadas e gerencie a conta de serviço e o recurso associado como uma unidade: aplique os mesmos processos, o mesmo ciclo de vida e a mesma vigilância à conta de serviço e ao recurso associado a ela e use as mesmas ferramentas para gerenciá-los.

Criar contas de serviço de finalidade única

O compartilhamento de uma única conta de serviço em vários aplicativos pode complicar o gerenciamento da conta de serviço:

  • Os aplicativos podem ter ciclos de vida diferentes. Se um aplicativo for desativado, talvez não esteja claro se a conta de serviço também pode ser desativada ou se ainda é necessário.
  • Com o tempo, os requisitos de acesso dos aplicativos podem divergir. Se os aplicativos usarem a mesma conta de serviço, talvez seja necessário conceder acesso à conta de serviço a um número cada vez maior de recursos, o que, por sua vez, aumenta o risco geral.
  • Os registros de auditoria do Cloud incluem o nome da conta de serviço que fez uma alteração ou acessou dados, mas não mostram o nome do aplicativo que usou a conta do serviço. Se vários aplicativos compartilharem uma conta de serviço, talvez não seja possível rastrear a atividade para o aplicativo correto.

Para evitar essas complicações, crie contas de serviço dedicadas para cada aplicativo e evite o uso de contas de serviço padrão.

Siga uma convenção de nomenclatura e documentação

Para ajudar a rastrear a associação entre um serviço e um aplicativo ou recurso, siga uma convenção de nomenclatura ao criar novas contas de serviço:

  • Adicione um prefixo ao endereço de e-mail da conta de serviço que identifica como a conta é usada. Por exemplo:
    • vm- para contas de serviço anexadas a uma instância de VM.
    • wi- para contas de serviço usadas pela identidade da carga de trabalho.
    • wif- para contas de serviço usadas pela federação de identidade da carga de trabalho.
    • onprem- para contas de serviço usadas por aplicativos locais.
  • Insira o nome do aplicativo no endereço de e-mail da conta de serviço. Por exemplo, vm-travelexpenses@ se a VM executar um aplicativo de despesas de viagem.
  • Use o campo de descrição para adicionar uma pessoa para contato, links para a documentação relevante ou outras observações.

Não inclua informações ou termos confidenciais no endereço de e-mail de uma conta de serviço.

Identificar e desativar contas de serviço não utilizadas

Quando uma conta de serviço não é mais utilizada, desative-a. Ao desativar contas de serviços não utilizadas, você reduz o risco de abuso das contas de serviço por causa de um comportamento inadequado ou de escalonamento de privilégios por parte de um usuário de má-fé.

Para contas de serviço de finalidade única associadas a um recurso específico, como uma instância de VM, desative a conta de serviço assim que o recurso associado for desativado ou excluído.

Para contas de serviço usadas para vários fins ou compartilhadas em vários recursos, pode ser mais difícil identificar se a conta de serviço ainda está sendo usada. Nesses casos, use os seguintes métodos:

Desative contas de serviço não utilizadas antes de excluí-las

Se você excluir uma conta de serviço e, em seguida, criar uma nova conta de serviço com o mesmo nome, uma identidade diferente será atribuída à nova conta de serviço. Como resultado, nenhuma das vinculações originais do IAM se aplicará à nova conta de serviço. Por outro lado, se você desativar e reativar uma conta de serviço, todas as vinculações do IAM permanecerão intactas.

Para evitar a perda acidental de vinculações do IAM, é melhor não excluir as contas de serviço imediatamente. Em vez disso, desative uma conta de serviço se ela não for mais necessária e só a exclua após um determinado período.

Nunca exclua contas de serviço padrão, como o App Engine ou a conta de serviço padrão do Compute Engine. Essas contas de serviço não podem ser recriadas sem desativar e reativar a respectiva API, o que pode interromper a implantação existente. Se você não usa as contas de serviço padrão, desative-as.

A seguir