Contas de serviço

Nesta página são explicadas as contas de serviço e os tipos de contas, além dos papéis de IAM disponíveis.

Antes de começar

  • Entenda os conceitos básicos do IAM.

O que são contas de serviço?

Uma conta de serviço é um tipo especial de conta usada por um aplicativo ou carga de trabalho de computação, como uma instância de máquina virtual (VM) do Compute Engine, em vez de uma pessoa. Os aplicativos usam contas de serviço para fazer chamadas de API autorizadas como a própria conta de serviço ou como um usuário do Google Workspace ou do Cloud Identity por meio da delegação em todo o domínio.

Por exemplo, uma conta de serviço pode ser anexada a uma VM do Compute Engine, para que os aplicativos executados nessa VM possam ser autenticados como a conta de serviço. Além disso, essa conta de serviço pode receber papéis do IAM que permitem acessar recursos. A conta de serviço é usada como a identidade do aplicativo, e os papéis da conta de serviço controlam quais recursos o aplicativo pode acessar.

Uma conta de serviço é identificada por seu endereço de e-mail, que é exclusivo.

Diferenças entre uma conta de serviço e uma conta de usuário

As contas de serviço diferem das contas de usuário de algumas maneiras principais:

  • As contas de serviço não têm senhas e não podem fazer login por meio de navegadores ou cookies.
  • As contas de serviço são associadas a pares de chaves RSA públicas/privadas usados para autenticação no Google e assinatura de dados.
  • É possível permitir que outros usuários ou contas de serviço personifiquem uma conta de serviço.
  • As contas de serviço não pertencem ao seu domínio do Google Workspace, diferentemente das contas de usuário. Se você compartilhar recursos do Google Workspace, como documentos ou eventos, com todo o domínio do Google Workspace, eles não serão compartilhados com contas de serviço. Da mesma forma, os recursos do Google Workspace criados por uma conta de serviço não são criados no seu domínio do Google Workspace. Como resultado, os administradores do Google Workspace e do Cloud Identity não podem ser proprietários nem gerenciar esses recursos.

Como impedir a criação de contas de serviço

É possível impedir a criação de contas de serviço aplicando a restrição de política da organização constraints/iam.disableServiceAccountCreation em uma organização, projeto ou pasta.

Antes de aplicar essa restrição, considere as seguintes limitações:

Contas de serviço e Grupos do Google

Adicione contas de serviço a um Grupo do Google e atribua papéis a ele. No entanto, não é recomendável adicionar contas de serviço a grupos. Contas de serviço são usadas por aplicativos, e cada aplicativo provavelmente terá os próprios requisitos de acesso.

Tipos de chaves para contas de serviço

Cada conta de serviço está associada a um par de chaves RSA públicas/privadas. A API Service Account Credentials usa esse par de chaves internas para criar credenciais de conta de serviço de curta duração e assinar blobs e tokens JSON da Web (JWTs, na sigla em inglês). Esse par é conhecido como par de chaves gerenciado pelo Google.

Além disso, é possível criar vários pares de chaves RSA públicas/privadas, conhecidos como pares de chaves gerenciadas pelo usuário, e usar a chave privada para autenticar com as APIs do Google. Essa chave privada é conhecida como chave da conta de serviço.

Pares de chaves gerenciadas pelo Google

Os pares de chaves gerenciados pelo Google são usados pela API Service Account Credentials e pelos serviços do Google Cloud, como o App Engine e o Compute Engine, para gerar credenciais de curta duração para contas de serviço.

Os pares de chaves gerenciados pelo Google são automaticamente rotacionados e usados para assinatura por no máximo duas semanas. O processo de rotação é baseado em probabilidades, e o uso da nova chave aumentará ou diminuirá a duração dela gradualmente.

A chave privada em um par de chaves gerenciado pelo Google sempre é mantida em garantia, e nunca é possível acessá-la diretamente.

A chave pública em um par de chaves gerenciado pelo Google é acessível publicamente para que qualquer pessoa possa verificar as assinaturas criadas com a chave privada. É possível acessar a chave pública em vários formatos diferentes:

  • Certificado X.509: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • Chave da Web JSON (JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
  • Formato bruto: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Se você fizer o download e o armazenamento em cache da chave pública, recomendamos armazená-la em cache por no máximo 24 horas para garantir que você sempre tenha a chave atual. Independentemente da data de recuperação da chave pública, ela será válida por pelo menos 24 horas após a recuperação.

Pares de chaves gerenciadas pelo usuário

É possível criar pares de chaves gerenciadas pelo usuário para uma conta de serviço e, em seguida, usar a chave privada de cada par de chaves para autenticar com as APIs do Google. Essa chave privada é conhecida como chave da conta de serviço. Cada conta de serviço pode ter até 10 chaves. O Google armazena apenas a parte pública de um par de chaves gerenciado pelo usuário.

Existem algumas maneiras diferentes de criar um par de chaves gerenciado pelo usuário para uma conta de serviço:

As chaves gerenciadas pelo usuário são credenciais extremamente eficientes e podem representar um risco de segurança quando não são gerenciadas corretamente. Para limitar o uso de chaves gerenciadas pelo usuário, é possível aplicar as seguintes restrições de política da organização a uma organização, um projeto ou uma pasta:

  • constraints/iam.disableServiceAccountKeyCreation: impede que os principais criem chaves de conta de serviço gerenciadas por usuários.
  • constraints/iam.disableServiceAccountKeyUpload: impede que os principais façam upload de uma chave pública para uma conta de serviço.

Se você impor essas restrições porque está usando a federação de identidade da carga de trabalho, considere usar as restrições da política da organização para a federação da identidade da carga de trabalho para especificar quais provedores de identidade são permitidos.

Como especificar um prazo de validade para chaves gerenciadas pelo usuário

Por padrão, quando você cria uma chave de conta de serviço gerenciada pelo usuário, a chave nunca expira. É possível alterar esse padrão definindo um prazo de validade para todas as chaves recém-criadas no projeto, na pasta ou na organização.

Use prazos de validade quando precisar de acesso temporário a um sistema, especialmente quando o sistema exigir uma chave de conta de serviço. Por exemplo, use prazos de validade nestes cenários:

  • Um desenvolvedor precisa concluir um codelab que exija chaves de conta de serviço.
  • Um desenvolvedor precisa executar uma ferramenta da CLI que requer uma chave de conta de serviço.
  • Funcionários temporários, como estagiários ou prestadores de serviços, estão criando uma prova de conceito para um novo aplicativo.

Evite usar prazos de validade nestes cenários:

  • Cargas de trabalho de produção. Na produção, uma chave de conta de serviço expirada pode causar uma interrupção acidental. Em vez disso, use chaves que não expirem e gerencie o ciclo de vida delas com a rotação de chaves.
  • Cargas de trabalho de não produção que precisam de acesso permanente, como um pipeline de integração contínua (CI).

Para definir um prazo de validade, use as Configurações de recursos para atualizar a configuração settings/iam-serviceAccountKeyExpiry. Depois de atualizar essa configuração para seu projeto, pasta ou organização, o prazo de validade se aplica a todas as chaves de conta de serviço recém-criadas nesse recurso pai. As chaves existentes não são afetadas.

Para detalhes sobre essa configuração, consulte o índice de configurações de recursos. Para saber como atualizar a configuração, consulte Alterar um valor de configuração local.

Como prática recomendada, use tempos de expiração curtos, como 8hours, 24hours ou 7days. Tempos de expiração curtos ajudam a garantir que sua equipe tenha um processo bem testado para atualizar chaves. Comece com o prazo de validade mais curto que atenda às suas necessidades e aumente-o apenas se necessário.

Tipos de contas de serviço

Contas de serviço gerenciadas pelo usuário

É possível criar contas de serviço gerenciadas pelo usuário no projeto usando a API do IAM, o Console do Cloud ou a Google Cloud CLI. Você é responsável por gerenciar e proteger essas contas.

Por padrão, é possível criar até 100 contas de serviço gerenciadas pelo usuário em um projeto. Se essa cota não atender às suas necessidades, use o Console do Cloud para solicitar um aumento de cota. As contas de serviço padrão descritas nessa página não são contabilizadas nessa cota.

Ao criar uma conta de serviço gerenciada pelo usuário no projeto, você escolhe um nome para a conta de serviço. Esse nome aparece no endereço de e-mail que identifica a conta de serviço, com o seguinte formato:

service-account-name@project-id.iam.gserviceaccount.com

Contas de serviço padrão

Quando você usa alguns serviços do Google Cloud, eles criam contas de serviço gerenciadas pelo usuário. Elas permitem que o serviço implante jobs que acessam outros recursos do Google Cloud. Essas contas são conhecidas como contas de serviço padrão.

Se seu aplicativo for executado em um ambiente do Google Cloud com uma conta de serviço padrão, o aplicativo poderá usar as credenciais da conta de serviço padrão para chamar as APIs do Google Cloud. Como alternativa, crie sua própria conta de serviço gerenciada pelo usuário e use-a para se autenticar. Para detalhes, consulte Como localizar credenciais automaticamente.

Esta tabela mostra os serviços que criam contas de serviço padrão:

Serviço Nome da conta de serviço Endereço de e-mail
App Engine e qualquer serviço do Google Cloud que use o App Engine Conta de serviço padrão do App Engine project-id@appspot.gserviceaccount.com
Compute Engine e qualquer serviço do Google Cloud que use o Compute Engine Conta de serviço padrão do Compute Engine project-number-compute@developer.gserviceaccount.com

Contas de serviço gerenciadas pelo Google

Alguns serviços do Google Cloud precisam acessar seus recursos para serem capazes de atuar em seu nome. Por exemplo, quando você usa o Cloud Run para executar um contêiner, o serviço precisa acessar qualquer tópico do Pub/Sub que possa acionar o contêiner.

Para atender a essa necessidade, o Google cria e gerencia contas de serviço de muitos serviços do Google Cloud. Elas são conhecidas como contas de serviço gerenciadas pelo Google. Talvez você veja as contas de serviço gerenciadas pelo Google na política de permissão do projeto, nos registros de auditoria ou na página do IAM no Console do Cloud.

As contas de serviço gerenciadas pelo Google não estão listadas na página Contas de serviço no Console do Cloud.

Exemplo:

  • Agente de serviço do Google APIs. A política de permissão do projeto provavelmente se refere a uma conta de serviço chamada agente de serviço de APIs do Google, com um endereço de e-mail que usa o seguinte formato: project-number@cloudservices.gserviceaccount.com

    Essa conta de serviço executa processos internos do Google em seu nome. Ele recebe automaticamente o papel de editor (roles/editor) no projeto.

  • Outros agentes de serviços. A política de permissão do projeto pode se referir a outras contas de serviço gerenciadas pelo Google que atuam em nome de serviços individuais. Essas contas de serviço às vezes são chamadas de agentes de serviços. Os papéis são concedidos automaticamente a esses agentes de serviços. Os nomes desses papéis normalmente terminam em serviceAgent.

    Para ver a lista completa de agentes de serviço e os papéis que são concedidos automaticamente a cada um, consulte Agentes de serviço.

  • Gerente de papéis para contas de serviço gerenciadas pelo Google. Os registros de auditoria do IAM podem se referir à conta de serviço service-agent-manager@system.gserviceaccount.com.

    Essa conta de serviço gerencia os papéis que são concedidos a outras contas de serviço gerenciadas pelo Google. Ela é visível apenas nos registros de auditoria.

    Por exemplo, se você usar uma nova API, o Google poderá criar automaticamente uma nova conta de serviço gerenciada pelo Google e conceder papéis a essa conta no seu projeto. A concessão desses papéis gera uma entrada de registro de auditoria, que mostra que service-agent-manager@system.gserviceaccount.com definiu a política de permissão para o projeto.

Locais da conta de serviço

Cada conta de serviço está localizada em um projeto. Depois de criar uma conta de serviço, não será possível movê-la para um projeto diferente.

Há algumas maneiras de organizar suas contas de serviço em projetos:

  • Crie contas de serviço e recursos no mesmo projeto.

    Com essa abordagem, é fácil começar a usar as contas de serviço. No entanto, pode ser difícil acompanhar suas contas de serviço quando elas estão espalhadas por vários projetos.

  • Centralizar as contas de serviço em projetos separados.

    Essa abordagem coloca todas as contas de serviço da sua organização em um pequeno número de projetos, o que pode facilitar o gerenciamento delas. No entanto, essa abordagem requer outras configurações se você anexar contas de serviço a recursos em outros projetos, o que permite que esses recursos usem a conta de serviço como identidade.

    Quando uma conta de serviço está em um projeto e acessa um recurso em outro projeto, geralmente é necessário ativar a API para esse recurso nos dois projetos. Por exemplo, se você tem uma conta de serviço no projeto my-service-accounts e uma instância do Cloud SQL no projeto my-application, você precisa ativar a API Cloud SQL em my-service-accounts e my-application.

    Por padrão, é possível criar até 100 contas de serviço em um projeto. Se você precisar criar contas de serviço adicionais, solicite um aumento de cota.

Permissões de conta de serviço

As contas de serviço são identities e recursos.

Como as contas de serviço são identidades, é possível permitir que uma conta de serviço acesse recursos em seu projeto ao conceder a ela um papel, assim como você faria para qualquer outro principal. Por exemplo, para permitir que a conta de serviço do aplicativo acesse objetos em um bucket do Cloud Storage, conceda à conta de serviço o papel de Leitor de objetos do Storage (roles/storage.objectViewer) no bucket.

No entanto, as contas de serviço também são recursos que aceitam políticas de permissão. Como resultado, é possível permitir que outros principais acessem uma conta de serviço concedendo a eles um papel na conta de serviço ou em um dos recursos pai da conta de serviço. Por exemplo, para permitir que um usuário personifique uma conta de serviço, conceda a ele o papel de usuário da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço.

Para mais informações sobre como conceder papéis aos principais, incluindo contas de serviço, consulte Como conceder, alterar e revogar o acesso.

Para mais informações sobre a concessão de papéis em contas de serviço, consulte Como gerenciar a representação da conta de serviço.

O papel de Usuário da conta de serviço

É possível conceder o papel de Usuário da conta de serviço (roles/iam.serviceAccountUser) no nível do projeto a todas as contas de serviço ou no nível da conta de serviço.

  • A concessão do papel de Usuário da conta de serviço a um usuário permite que ele acesse todas as contas de serviço do projeto, inclusive as que forem criadas no futuro.

  • A concessão do papel de Usuário da conta de serviço a um usuário para uma conta de serviço específica concede a ele acesso somente a essa conta de serviço.

Os usuários que receberam o papel de Usuário da conta de serviço em uma conta de serviço podem usá-lo para acessar indiretamente todos os recursos acessíveis a essa conta. Por exemplo, se uma conta de serviço tiver recebido o papel de Administrador do Compute (roles/compute.admin), um Usuário da conta de serviço, a quem foi concedido esse papel, (roles/iam.serviceAccountUser) agirá como a conta de serviço para iniciar uma instância do Compute Engine. Nesse fluxo, o usuário se faz passar pela conta de serviço para executar qualquer tarefa usando os papéis e as permissões concedidas.

Para mais informações sobre a concessão de papéis de usuários em contas de serviço, consulte Como gerenciar a personificação da 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 externas, 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 Como entender as contas de serviço.

O papel de Criador de token da conta de serviço

Esse papel permite a representação de contas de serviço para criar tokens de acesso OAuth2, bloquear blobs ou assinar JWTs.

Access scopes

Os escopos de acesso são um método legado que especifica permissões de uma instância de máquina virtual (VM, na sigla em inglês) do Compute Engine. Eles definem os escopos do OAuth padrão usados nas solicitações da CLI gcloud e das bibliotecas de cliente.

O Google Cloud agora usa o IAM, não os escopos de acesso, para especificar permissões para instâncias do Compute Engine. No entanto, ainda é preciso definir um escopo de acesso ao configurar uma instância para personificar uma conta de serviço.

Para mais informações, consulte a documentação do Compute Engine.

Credenciais de conta de serviço de curta duração

É possível criar credenciais de curta duração que permitam assumir a identidade de uma conta de serviço do Google Cloud. Essas credenciais podem ser usadas para autenticar chamadas de APIs do Google Cloud ou outras APIs que não são do Google.

O caso de uso mais comum dessas credenciais é delegar temporariamente o acesso aos recursos do Google Cloud em diferentes projetos, organizações ou contas. Por exemplo, em vez de fornecer as credenciais permanentes de uma conta de serviço altamente privilegiada a um autor de chamada externo, você pode conceder acesso de emergência temporário. Como alternativa, uma conta de serviço designada com menos permissões pode ser representada por um autor de chamada externo sem exigir credenciais de uma conta de serviço com mais privilégios.

Para mais informações, consulte Como criar credenciais de conta de serviço de curta duração.

Federação de identidade da carga de trabalho

É possível conceder às identidades a capacidade de personificar uma conta de serviço em uma carga de trabalho executada fora do Google Cloud, como no Amazon Web Services (AWS) ou no Microsoft Azure. Isso permite que você acesse recursos diretamente, usando credenciais de curta duração, em vez de usar uma chave de conta de serviço.

Saiba mais em Federação de identidades de carga de trabalho.

Application Default Credentials

O Application Default Credentials é uma ferramenta que as bibliotecas de cliente do Google Cloud usam para descobrir automaticamente as credenciais da conta de serviço. É possível especificar uma chave de conta de serviço em uma variável de ambiente, e o Application Default Credentials a usará automaticamente. Se você não especificar uma chave, o Application Default Credentials usará a conta de serviço anexada ao recurso que está executando seu código ou a conta de serviço padrão do serviço que está executando seu código.

Para saber mais, consulte Como encontrar credenciais automaticamente.

A seguir

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