Sobre as contas de serviço no GKE

Neste documento, 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 tipo para autenticar o acesso a recursos no GKE sem depender de credenciais pessoais.

Este documento é destinado 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 tarefas de exemplo referenciados 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-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

CLUSTER_PROJECT_NUMBER é o número do projeto do projeto que contém seu cluster do GKE.

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 para 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 de 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-CLUSTER_PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

CLUSTER_PROJECT_NUMBER é o número do projeto do projeto que contém seu cluster do GKE.

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.

Contas de serviço de nó

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.

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.

Endereços de e-mail das contas de serviço de nós

O endereço de e-mail da conta de serviço do nó depende do tipo de conta de serviço, da seguinte maneira:

  • Conta de serviço padrão do Compute Engine:

    CLUSTER_PROJECT_NUMBER-compute@developer.gserviceaccount.com

    Substitua CLUSTER_PROJECT_NUMBER pelo número do projeto que contém o cluster, como 1234567890.

  • Conta de serviço personalizada:

    SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.com

    Substitua:

    • SERVICE_ACCOUNT_NAME: o nome da conta de serviço.
    • SERVICE_ACCOUNT_PROJECT_ID: o ID do projeto do Google Cloud projeto que contém a conta de serviço.

Contas de serviço de nó e agentes de serviço do projeto

Ao criar um cluster ou um pool de nós, os agentes de serviço no projeto do cluster usam a conta de serviço anexada aos nós para realizar tarefas como extrações de imagens. Por padrão, os agentes de serviço no projeto do cluster têm o seguinte acesso às contas de serviço de nós nesse projeto:

  • O agente de serviço do Compute Engine em um projeto pode criar tokens de acesso para contas de serviço de nós no mesmo projeto.
  • O agente de serviço do GKE em um projeto pode representar contas de serviço de nós no mesmo projeto.

Algumas organizações usam um projeto dedicado para gerenciar todas as contas de serviço. Se a conta de serviço do nó não estiver no projeto do cluster, os agentes de serviço no projeto do cluster não poderão criar tokens nem simular essa conta de serviço. É preciso conceder aos agentes de serviço no projeto de cluster os seguintes papéis na conta de serviço:

Para mais informações, consulte Configurar o uso da conta de serviço em vários projetos.

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