Identidade da carga de trabalho


A Identidade da carga de trabalho é a maneira recomendada para suas cargas de trabalho em execução no Google Kubernetes Engine (GKE) acessarem os serviços do Google Cloud de maneira segura e gerenciada.

Para mais informações sobre como ativar e usar a Identidade da carga de trabalho no GKE, consulte Usar identidade da carga de trabalho.

É possível usar a identidade da carga de trabalho da frota para fornecer suporte à federação de identidade da carga de trabalho para clusters registrados em frutas, incluindo clusters do Anthos.

Terminologia

Neste documento, diferenciamos as contas de serviço do Kubernetes das contas de serviço de gerenciamento de identidade e acesso (IAM).

Contas de Serviço Kubernetes
Recursos do Kubernetes que fornecem uma identidade para processos em execução nos pods do GKE.
Contas de serviço do IAM
Recursos do Google Cloud que permitem que os aplicativos façam chamadas autorizadas para as APIs do Google Cloud.

O que é a Identidade da carga de trabalho?

Os aplicativos em execução no GKE talvez precisem de acesso às APIs do Google Cloud, como a API Compute Engine, a API BigQuery Storage ou as APIs Machine Learning.

A Identidade da carga de trabalho permite que uma conta de serviço do Kubernetes no cluster do GKE atue como uma conta de serviço do IAM. Os pods que usam a conta de serviço configurada do Kubernetes serão autenticados automaticamente como a conta de serviço do IAM ao acessar as APIs do Google Cloud. O uso da identidade de carga de trabalho permite que você atribua identidades e autorizações distintas e refinadas para cada aplicativo no cluster.

Como a Identidade da carga de trabalho funciona

Quando você ativa a identidade da carga de trabalho em um cluster, o GKE cria automaticamente um pool de identidades de carga de trabalho fixo para o projeto do Google Cloud do cluster. Um pool de identidade de carga de trabalho permite que o IAM entenda e confie nas credenciais da conta de serviço do Kubernetes. O pool de identidades de carga de trabalho tem o seguinte formato:

PROJECT_ID.svc.id.goog

O GKE usa esse pool para todos os clusters no projeto que usam a identidade da carga de trabalho.

Quando você configura uma conta de serviço do Kubernetes em um namespace para usar a Identidade da carga de trabalho, o IAM autentica as credenciais usando o seguinte nome do membro:

serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KUBERNETES_SERVICE_ACCOUNT]

Neste nome de membro:

  • PROJECT_ID: é seu ID do projeto no Google Cloud.
  • KUBERNETES_NAMESPACE, o namespace da conta de serviço do Kubernetes.
  • KUBERNETES_SERVICE_ACCOUNT é o nome da conta de serviço do Kubernetes que fez a solicitação.

O processo de configuração da Identidade da carga de trabalho inclui o uso de uma vinculação de política do IAM para vincular o nome do membro da conta de serviço do Kubernetes a uma conta de serviço do IAM que tenha as permissões necessárias às cargas de trabalho. Todas as chamadas da API Google Cloud de cargas de trabalho que usam essa conta de serviço do Kubernetes são autenticadas como a conta de serviço do IAM vinculada.

Semelhança de identidade

O nome do membro que o IAM usa para verificar uma conta de serviço do Kubernetes com a identidade da carga de trabalho usa as seguintes variáveis:

  • O nome da conta de serviço do Kubernetes.
  • O namespace da conta de serviço do Kubernetes.
  • O ID do projeto do Google Cloud.

Se o projeto tiver vários clusters com o mesmo nome e namespace para uma conta de serviço do Kubernetes, todas as contas terão o mesmo nome de membro. Essa identidade comum permite que você conceda acesso aos recursos do Google Cloud para o pool de identidades da carga de trabalho em vez de clusters individuais.

Por exemplo, considere o diagrama a seguir. Os clusters A, B e C pertencem ao mesmo projeto do Google Cloud e, portanto, ao mesmo pool de identidades de carga de trabalho. Os aplicativos no namespace backend do Cluster A e do Cluster B podem ser autenticados como a conta de serviço do IAM back ao acessar os recursos do Google Cloud. O IAM não faz distinção entre os clusters que fazem as chamadas.

Diagrama ilustrando a semelhança de identidade em um pool de identidades de carga de trabalho
Semelhança da identidade que acessa as APIs do Google Cloud com identidade da carga de trabalho

Essa semelhança de identidade também significa que você precisa confiar em todos os clusters em um pool de identidades de carga de trabalho específico. Por exemplo, se o Cluster C no exemplo anterior pertencesse a uma equipe não confiável, seria possível criar um namespace backend e acessar as APIs do Google Cloud usando a conta de serviço back do IAM. assim como os Clusters A e B.

Para evitar o acesso não confiável, coloque os clusters em projetos separados para garantir que eles tenham pools de identidade de carga de trabalho diferentes ou que os nomes de namespace sejam diferentes para evitar um nome de membro comum.

Noções básicas do servidor de metadados do GKE

Cada nó em um GKE com a Identidade da carga de trabalho ativada armazena os metadados no servidor de metadados do GKE. O servidor de metadados do GKE é um subconjunto dos endpoints do servidor de metadados do Compute Engine necessários para as cargas de trabalho do Kubernetes.

O servidor de metadados do GKE é executado como um DaemonSet, com um pod em cada nó do Linux ou um serviço do Windows nativo em cada nó do Windows no cluster. O servidor de metadados intercepta solicitações HTTP para http://metadata.google.internal (169.254.169.254:80). Por exemplo, a solicitação GET /computeMetadata/v1/instance/service-accounts/default/token recupera um token para a conta de serviço do IAM que o pod está configurado para personificar. O tráfego para o servidor de metadados nunca sai da instância de VM que hospeda o pod.

Veja nas tabelas a seguir o subconjunto de endpoints do servidor de metadados do Compute Engine disponíveis com o servidor de metadados do GKE. Para uma lista completa de endpoints disponíveis no servidor de metadados do Compute Engine, consulte Valores de metadados da VM padrão.

Metadados de instância

Os metadados da instância são armazenados no diretório a seguir.

http://metadata.google.internal/computeMetadata/v1/instance/

Entrada Descrição
hostname

O nome do host do nó.

id

O ID exclusivo do seu nó.

service-accounts/

Um diretório das contas de serviço associadas à instância. As seguintes informações estão disponíveis para cada conta de serviço:

  • aliases
  • email: o endereço de e-mail da conta de serviço,
  • identity: um JSON Web Token (JWT) exclusivo para o nó. Você precisa incluir o parâmetro audience na solicitação. Por exemplo, ?audience=http://www.example.com.
  • scopes: os escopos de acesso atribuídos à conta de serviço.
  • token: o token de acesso do OAuth 2.0 para autenticar suas cargas de trabalho.
zone

A zona do Compute Engine do seu nó do GKE.

Atributos da instância

Os atributos da instância são armazenados no seguinte diretório.

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

Entrada Descrição
cluster-location

A zona ou a região do Compute Engine do cluster.

cluster-name

: o nome do cluster do GKE.

cluster-uid

O UID do seu cluster do GKE.

Metadados do projeto

Os metadados do projeto de cluster são armazenados no diretório a seguir.

http://metadata.google.internal/computeMetadata/v1/project/

Entrada Descrição
project-id

É o ID do seu projeto no Google Cloud.

numeric-project-id

: o número do projeto do Google Cloud.

Alternativas à Identidade da carga de trabalho

É possível usar uma das alternativas a seguir para a identidade da carga de trabalho para acessar as APIs Google Cloud no GKE.

  • Exporte as chaves da conta de serviço e armazene-as como secrets do Kubernetes. As chaves da conta de serviço do Google não expiram e exigem rotação manual. A exportação de chaves da conta de serviço tem o potencial de expandir o escopo de uma violação de segurança se ela não for detectada. Se uma chave exportada for roubada, um invasor poderá usá-la para se autenticar como essa conta de serviço até que você perceba e revogue a chave manualmente.

  • Use a conta de serviço padrão do Compute Engine dos nós. É possível executar pools de nós como qualquer conta de serviço do IAM no projeto. Se você não especificar uma conta de serviço durante a criação do pool de nós, o GKE usará a conta de serviço padrão do Compute Engine para o projeto. A conta de serviço do Compute Engine é compartilhada por todas as cargas de trabalho implantadas no nó. Isso pode resultar no provisionamento excessivo de permissões, o que viola o princípio do menor privilégio e é inadequado para clusters multilocatários.

A seguir