Sobre as contas de serviço no GKE

Nesta página, descrevemos as contas de serviço no Google Kubernetes Engine (GKE) e como elas fornecem identidades para aplicativos. Você vai aprender sobre os diferentes tipos de contas de serviço e quando usar cada um deles para autenticar o acesso a recursos no GKE sem depender de credenciais pessoais.

Esta página é destinada a especialistas em segurança e operadores que criam e gerenciam contas de serviço para interagir com aplicativos do GKE. Para saber mais sobre papéis comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.

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. Por padrão, esse volume projetado tem um nome que começa com o prefixo kube-api-access-. Todos os volumes que começam com esse prefixo são gerenciados pelo GKE, o que significa que não é possível modificar o tamanho deles. Para um monitoramento mais preciso do uso de disco, exclua da configuração de monitoramento os volumes que começam com o prefixo kube-api-access-.

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.

Credenciais comprometidas 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 que Google Cloud gerencia. O GKE usa os dois agentes de serviço a seguir:

Agente de serviço do Kubernetes Engine

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.

Agente de serviço de nós padrão do Kubernetes Engine

O GKE usa o agente de serviço de nó padrão do Kubernetes Engine para oferecer suporte à geração de registros e ao monitoramento de nós do Kubernetes em clusters que usam a versão 1.33 ou mais recente do Kubernetes. Esse agente de serviço tem o domínio gcp-sa-gkenode.iam.gserviceaccount.com e recebe o papel Agente de serviço do nó padrão do Kubernetes Engine (roles/container.defaultNodeServiceAgent) no projeto quando você ativa a API GKE.

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

service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

PROJECT_NUMBER é o número do projeto.

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.

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

O GKE usa contas de serviço do IAM anexadas aos nós para executar tarefas do sistema, como geração de registros e monitoramento. No mínimo, essas contas de serviço de nó precisam ter o papel Conta de serviço de nó padrão do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no seu projeto. Por padrão, o GKE usa a conta de serviço padrão do Compute Engine, que é criada automaticamente no seu projeto, como a conta de serviço do nó.

Se a organização aplicar a restrição da política da organização iam.automaticIamGrantsForDefaultServiceAccounts, a conta de serviço padrão do Compute Engine no projeto talvez não receba automaticamente as permissões necessárias para o GKE.

Se você usar a conta de serviço padrão do Compute Engine para outras funções no projeto ou na organização, ela poderá ter mais permissões do que o GKE precisa, o que pode expor você a riscos de segurança.

Para conceder o papel roles/container.defaultNodeServiceAccount à conta de serviço padrão do Compute Engine, siga estas etapas:

Console

  1. Acesse a página Boas-vindas:

    Acessar "Boas-vindas"

  2. No campo Número do projeto, clique em Copiar para a área de transferência.
  3. Acesse a página do IAM:

    Acessar IAM

  4. Clique em CONCEDER ACESSO.
  5. No campo Novos principais, especifique o seguinte valor: 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     Substitua PROJECT_NUMBER pelo número do projeto que você copiou.
  6. No menu Selecionar um papel, escolha o papel Conta de serviço de nó padrão do Kubernetes Engine.
  7. Clique em Salvar.

gcloud

  1. Encontre o número do seu projeto Google Cloud : 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    Substitua PROJECT_ID pela ID do seu projeto.

    O resultado será assim:

    12345678901
  2. Conceda o papel roles/container.defaultNodeServiceAccount à conta de serviço padrão do Compute Engine: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    Substitua PROJECT_NUMBER pelo número do projeto da etapa anterior.

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.

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

A seguir