Sobre as contas de serviço no GKE


Nesta página, descrevemos as contas de serviço no Google Kubernetes Engine (GKE), que fornecem identidades para aplicativos.

As contas de serviço são identidades destinadas ao uso por aplicativos em vez de pessoas. No GKE, você interage com as contas de serviço do Kubernetes e com as contas de serviço do Identity and Access Management.

Contas de serviço do Kubernetes e contas de serviço do IAM

A tabela a seguir descreve as principais diferenças entre as contas de serviço do Kubernetes e as do IAM:

Tipos de contas de serviço no GKE
Conta de serviço do Kubernetes
  • Objeto ServiceAccount no servidor da API Kubernetes
  • Tem um namespace do Kubernetes definido como escopo em um cluster
  • Fornece uma identidade para os pods usarem dentro do cluster
Conta de serviço do IAM
  • Gerenciar com a API IAM
  • No escopo de um projeto do Google Cloud
  • Fornece uma identidade para os aplicativos no projeto

Contas de Serviço Kubernetes

As contas de serviço do Kubernetes são gerenciadas no nível do cluster e existem no servidor da API Kubernetes como objetos ServiceAccount. Na documentação do Kubernetes e do GKE, geralmente são usados o termo ServiceAccount para distinguir esses recursos do Kubernetes das contas de serviço em outros ambientes, como o IAM.

Crie uma conta de serviço do Kubernetes em um namespace e atribua essa conta a um pod usando o campo serviceAccountName no manifesto do pod. O processo do kubelet no nó recebe um token do portador de curta duração para a ServiceAccount atribuída e monta o token como um volume projetado no pod.

O token do portador de curta duração é um token da Web JSON (JWT) assinado pelo servidor de API, que é um provedor OpenID Connect (OIDC). Para validar o token do portador, receba a chave de validação pública do cluster chamando o método projects.locations.clusters.getJwks na API GKE.

Como fazer a rotação das credenciais da conta de serviço do Kubernetes

Se uma credencial de conta de serviço do Kubernetes for comprometida, use uma das seguintes opções para revogar as credenciais:

  • Recrie seus pods: o token do portador está vinculado a cada UID de pod exclusivo. Portanto, recriar os pods invalida as credenciais anteriores.
  • Recrie a conta de serviço do Kubernetes: o token do portador está vinculado ao UID do objeto ServiceAccount na API Kubernetes. Exclua a ServiceAccount e crie uma nova ServiceAccount com o mesmo nome. Os tokens anteriores se tornam inválidos porque o UID da nova ServiceAccount é diferente.
  • Executar uma rotação de credenciais: essa operação revoga todas as credenciais da conta de serviço do Kubernetes no cluster. A rotação também altera o certificado de CA e o endereço IP do seu cluster. Para mais detalhes, consulte rotação de credenciais.

Contas de serviço do IAM

As contas de serviço do IAM são gerenciadas no nível do projeto usando a API IAM. É possível usar essas contas de serviço para executar ações como chamar programaticamente APIs do Google Cloud e gerenciar permissões para aplicativos em execução nos produtos do Google Cloud.

Para saber mais, consulte a visão geral das contas de serviço do IAM.

Agentes de serviço do GKE

Um agente de serviço do IAM é uma conta de serviço do IAM gerenciada pelo Google Cloud.

O GKE usa o agente de serviço do Kubernetes Engine para gerenciar o ciclo de vida dos recursos do cluster em seu nome, como nós, discos e balanceadores de carga. Esse agente de serviço tem o domínio container-engine-robot.iam.gserviceaccount.com e recebe o papel Agente de serviço do Kubernetes Engine (roles/container.serviceAgent) no projeto quando você ativa a API GKE.

O identificador desse agente de serviço é o seguinte:

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

PROJECT_NUMBER é o número do projeto.

Se você desativar o agente de serviço do GKE, poderá recuperá-lo seguindo as instruções em Como ativar uma conta de serviço.

Se você remover as permissões do agente de serviço no projeto, poderá recuperá-las seguindo as instruções em Erro 400/403: permissões de edição ausentes na conta.

Se você excluir o agente de serviço do GKE, será possível cancelar a exclusão seguindo as instruções em Como cancelar a exclusão de uma conta de serviço.

Conta de serviço padrão de nó do GKE

Por padrão, os nós do GKE usam a conta de serviço padrão do Compute Engine. Por padrão, essa conta de serviço recebe o papel de Editor (roles/editor) e tem mais permissões do que as necessárias para os nós do GKE. Considere usar um papel que use as permissões mínimas necessárias para executar nós no cluster.

Não desative a conta de serviço padrão do Compute Engine, a menos que esteja migrando para contas de serviço gerenciadas pelo usuário.

Permissões mínimas

O GKE requer um conjunto mínimo de permissões de IAM para operar seu cluster. Para instruções sobre como criar uma conta de serviço do IAM com privilégios mínimos, consulte Usar contas de serviço do Google com privilégio mínimo.

Quando usar uma conta de serviço específica

O tipo de conta de serviço usado depende do tipo de identidade que você quer fornecer aos aplicativos, da seguinte maneira:

  • Forneça uma identidade para os pods usarem no cluster: use uma conta de serviço do Kubernetes. Todos os namespaces do Kubernetes têm uma ServiceAccount default, mas recomendamos que você crie novas ServiceAccounts com privilégios mínimos para cada carga de trabalho em cada namespace.
  • Forneça uma identidade para seus pods usarem fora do cluster: use a federação de identidade da carga de trabalho para GKE. A federação de identidade da carga de trabalho para GKE permite especificar recursos do Kubernetes, como ServiceAccounts como principais nas políticas do IAM. Por exemplo, use a federação de identidade da carga de trabalho para o GKE ao chamar APIs do Google Cloud, como Secret Manager ou Spanner, nos seus pods.
  • Forneça uma identidade padrão para os nós: use uma conta de serviço do IAM com privilégios mínimos personalizada ao criar os clusters ou nós do GKE. Se você não usar uma conta de serviço personalizada do IAM, o GKE usará a conta de serviço padrão do Compute Engine, que tem permissões abrangentes no projeto.

A seguir