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 será executado o código que assume a identidade da conta de serviço: no Google Cloud Platform 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 Google Compute Engine e deseja que ele tenha permissão apenas para criar objetos no Google 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 contas de serviço.

Como personificar uma conta de serviço

Há três maneiras de personificar uma conta de serviço para acessar as APIs do Google:

  • Autenticação usando chaves privadas RSA
  • Autorização usando políticas do Cloud IAM
  • Implantação de jobs nos serviços do Google Cloud

Autenticação usando chaves privadas RSA

Todas as contas de serviço têm pares de chaves gerenciadas pelo Google Cloud que são revezadas regularmente. As chaves privadas são mantidas como garantia pela plataforma e não podem ser acessadas diretamente.

Também é possível criar manualmente um par de chaves gerenciado pelo usuário. O Google Cloud gerará as chaves privada/pública, armazenando a chave pública e fornecendo a chave privada ao usuário. O par de chaves não conseguirá se autenticar no Google quando o par de chaves tiver sido excluído da conta de serviço.

Autorização usando políticas do Cloud IAM

Todas as contas de serviço têm políticas do Cloud IAM que concedem acesso à conta de serviço. Algumas permissões permitem que os usuários personifiquem ou se tornem a conta de serviço com base nas credenciais dos usuários.

Como implantar jobs no Google Cloud

Alguns serviços do Google Cloud, como Compute Engine, App Engine ou Cloud Functions, permitem implantar um job (como uma VM ou uma função) que é executado como a identidade de uma conta de serviço.

Para implantar jobs dessa maneira, a conta de serviço precisa receber as permissões necessárias para o serviço pretendido, e a conta de usuário também precisa receber a permissão iam.serviceAccounts.actAs na conta de serviço. Essa permissão está incluída no papel de Usuário da conta de serviço. Também é necessário que o serviço do Google Cloud mantenha permissões do Cloud IAM na conta de serviço, mas isso geralmente é feito automaticamente para você.

Exemplos

Como executar uma VM com uma conta de serviço

Digamos que você tenha um job de longa duração que os funcionários tenham permissões para iniciar. O ideal é que esse job não seja encerrado quando o funcionário que o iniciou saia da empresa.

Para resolver esse problema, crie uma conta de serviço que inicie e interrompa o job. Siga as etapas abaixo:

  1. Crie uma conta de serviço.

  2. Conceda o papel de Usuário da conta de serviço (roles/iam.serviceAccountUser) aos funcionários que precisam de permissão para iniciar o job. Nesse cenário, a conta de serviço é tratada como recurso.

  3. Conceda o papel de Administrador de instância do Compute (roles/compute.instanceAdmin.v1) aos mesmos funcionários.

  4. Agora, os funcionários podem criar instâncias do Compute Engine que executam essa conta de serviço, conectar-se a elas e usar a conta para iniciar o job. Exemplo:

    gcloud compute instances create my-instance --scopes=cloud-platform \
        --service-account=my-service-account@test9q.iam.gserviceaccount.com \
        --zone=us-central1-a
        

Como migrar dados para o Google Cloud

Suponha que alguns dados sejam processados em outro provedor de nuvem e você quer transferi-los para o Google Cloud Platform. Use uma conta de serviço das máquinas virtuais na nuvem externa para inserir os dados no Google Cloud Platform. Quando essa conta for criada, crie e faça o download da chave dela. Use essa chave no processo externo para chamar as APIs do Cloud Platform.

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 excluir e recriar contas de serviço

É possível excluir uma conta de serviço e criar uma nova com o mesmo nome. Se você reutilizar o nome de uma conta de serviço excluída, isso poderá causar um comportamento inesperado.

Quando você exclui uma conta de serviço, as respectivas associações de papéis não são removidas imediatamente. Se você criar uma nova conta de serviço com o mesmo nome de uma recém-excluída, as associaçõ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. Isso ocorre porque as contas de serviço recebem um código exclusivo no Cloud IAM durante a criação. Internamente, todas as associações de papéis são concedidas usando esses códigos, 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.

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, siga estas etapas:

  1. Crie a nova conta de serviço.
  2. Para cada recurso que a nova conta de serviço precisa acessar, revogue todos os papéis concedidos à conta de serviço original para esse recurso.

  3. Depois de revogar os papéis da conta de serviço original, conceda-os à nova conta de serviço.

Permissões para contas de serviço

Nesta seção, descrevemos cenários comuns para 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

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 uma conta de serviço para recursos específicos.

Ao conceder permissões de acesso para uma conta de serviço aos usuários, lembre-se de que eles poderão acessar todos os recursos permitidos a essa 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.

Usuários com papéis do Cloud IAM para atualizar as instâncias do App Engine e do Compute Engine, como Implantador do App Engine ou Administrador da instância do Compute, podem executar 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. Esta seção descreve cenários comuns e as permissões necessárias.

Como iniciar jobs de longa duração

Permissões:

  • iam.serviceAccounts.actAs

Papéis:

  • roles/editor (Editor)
  • roles/iam.serviceAccountUser (Usuário da conta de serviço)

Um usuário (ou serviço) pode associar uma conta de serviço a um serviço de job de longa duração. Veja alguns exemplos:

  • VM do Compute Engine
  • Aplicativo do App Engine
  • Função do Cloud Functions
  • Job do Dataflow

Nesse cenário, o usuário precisa receber a permissão para implantar o job, que varia por serviço, e a permissão para personificar a conta de serviço, concedida por meio de iam.serviceAccounts.actAs na conta de serviço. A concessão da permissão iam.serviceAccounts.actAs por si só não permite a personificação da conta de serviço.

Depois que a permissão iam.serviceAccounts.actAs for concedida à conta de serviço, ela poderá iniciar um job de longa duração executado como a conta de serviço. Depois que o job é iniciado, esse usuário não precisa mais ter acesso à conta de serviço. O job continuará em execução mesmo se esse usuário perder o acesso. O serviço de job continua a usar as próprias permissões na conta de serviço para manter o job em execução com essa identidade de conta de serviço.

Às vezes, é necessário ter a permissão iam.serviceAccounts.actAs para alterar um job de longa duração, como definir os metadados da instância em uma VM do Compute Engine.

Para mais informações sobre esse fluxo, consulte Como criar e ativar contas de serviço para instâncias na documentação do Compute Engine.

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 privadas 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 GCP. Essas chaves são usadas por serviços do Cloud Platform 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. Elas expiram 10 anos após a criação e deixam de ser autenticadas com êxito quando são excluídas da conta de serviço.

No caso de chaves gerenciadas pelo usuário, verifique se você tem processos que satisfaçam aos requisitos de gerenciamento de chaves, como estes:

  • 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 Google Compute Engine precisam ser executadas como contas de serviço para terem acesso a outros recursos do Cloud Platform. Para garantir a segurança das instâncias do Compute Engine, pense no seguinte:

  • Crie 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, você consegue 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 Cloud Platform. Por isso, evite excluí-las quando ainda estiverem sendo usadas pelas instâncias. Se as contas forem excluídas, podem ocorrer falhas nas operações das instâncias.

Práticas recomendadas

  • Restrinja quem pode atuar como conta de serviço. Os usuários com papéis de Usuários de contas 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 uma conta de serviço para recursos específicos.

  • 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.