Sobre a federação de identidade da carga de trabalho da frota

Nesta página, descrevemos a federação de identidade da carga de trabalho da frota, um mecanismo para autenticar solicitações de cargas de trabalho da frota para APIs do Google Cloud . Nesta página, você vai aprender sobre a semelhança de identidade para cargas de trabalho, como funciona a federação de identidade da carga de trabalho da frota e as práticas recomendadas para gerenciar isso em grande escala.

Esta página é destinada a administradores e operadores de plataforma e engenheiros de segurança que querem gerenciar a autorização de carga de trabalho de maneira mais eficiente em grande escala. Para saber mais sobre as funções de usuário e as tarefas de exemplo referenciadas na documentação do Google Cloud, consulte Funções e tarefas comuns do usuário do GKE.

Antes de ler esta página, você deve conhecer os seguintes conceitos:

Sobre identidades federadas da carga de trabalho em Google Cloud

A Federação de identidade da carga de trabalho é um Google Cloud recurso que permite que as cargas de trabalho nos clusters sejam autenticadas no Google Cloud sem que você precise fazer o download, alternar manualmente e gerenciar credenciais. Em vez disso, as cargas de trabalho são autenticadas usando tokens de curta duração gerados pelo Google Cloud.

A federação de identidade da carga de trabalho para o GKE é uma implementação específica do GKE da federação de identidade da carga de trabalho que fornece um pool de identidade da carga de trabalho gerenciado pelo Google em todo o projeto, do qual os aplicativos em execução nos clusters do GKE recebem identidades. A federação de identidade da carga de trabalho da frota estende a federação de identidade da carga de trabalho para o GKE a todos os clusters de membros da frota, independentemente de estarem em projetos diferentes ou fora do Google Cloud. Com a federação de identidade da carga de trabalho da frota, os clusters registrados que têm a federação de identidade da carga de trabalho ativada na assinatura da frota recebem identidades usando um pool de identidades de carga de trabalho gerenciado pelo Google em toda a frota. Esse pool compartilhado permite configurar a autenticação nas APIs do Google Cloud e em outros serviços em toda a frota, até mesmo em vários projetos.

A Federação de identidade da carga de trabalho da frota também pode ser usada pelo agente do Connect em alguns tipos de cluster para autenticação no Google Cloud como parte da associação da frota. Ela também é necessária para usar alguns recursos do GKE que funcionam em vários projetos, como o Cloud Service Mesh.

Sobre os pools de identidade da carga de trabalho

Um pool de identidades de carga de trabalho é uma entidade que gerencia de forma centralizada as identidades dos seus aplicativos. Quando você ativa a federação de identidade da carga de trabalho para GKE nos clusters, o projeto do cluster recebe um pool de identidades de carga de trabalho gerenciado pelo Google com um nome fixo e específico do projeto. Os aplicativos nos clusters recebem identidades do pool de identidades de carga de trabalho gerenciado pelo Google para autenticar chamadas de API Google Cloud . O pool de identidades de carga de trabalho gerenciado pelo Google tem a sintaxe PROJECT_ID.svc.id.goog, em que PROJECT_ID é o ID do projeto do cluster.

Com a federação de identidade da carga de trabalho da frota, o pool de identidade da carga de trabalho gerenciado pelo Google do projeto host da frota também é o pool de identidade da carga de trabalho de todos os clusters registrados na frota, independentemente de estarem em outros projetos ou fora de Google Cloud. Cada cluster na frota usa o pool de identidades de carga de trabalho FLEET_HOST_PROJECT_ID.svc.id.goog, em que FLEET_HOST_PROJECT_ID é o ID do projeto host da frota.

Se você usa escopos de equipe, é possível configurar um pool de identidade da carga de trabalho do IAM autogerenciado para os clusters usarem além do pool gerenciado pelo Google. Esse pool autogerenciado oferece um controle mais explícito sobre quais cargas de trabalho recebem identidades específicas.

Cada aplicativo na frota recebe uma identidade federada distinta do pool de identidade da carga de trabalho da frota, que pode ser usada para autenticar no Google Cloud e em outros serviços que você desenvolve. Os aplicativos recebem um identificador principal que o IAM pode reconhecer. Esse identificador usa a seguinte sintaxe:

PREFIX://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/SELECTOR

Essa sintaxe tem os seguintes campos:

  • PREFIX: principal ou principalSet, dependendo do tipo de recurso do Kubernetes selecionado no campo SELECTOR.
  • FLEET_PROJECT_NUMBER: o número do projeto host da frota.

  • WORKLOAD_IDENTITY_POOL_NAME: o pool de identidade da carga de trabalho da sua frota. Esse valor depende do pool de identidades de carga de trabalho que você configurou em cada cluster, da seguinte maneira:

    • Pool de identidades da carga de trabalho gerenciado pelo Google: FLEET_HOST_PROJECT_ID.svc.id.goog

    • Pool de identidades da carga de trabalho autogerenciado (prévia): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, em que POOL_HOST_PROJECT_NUMBER é o número do projeto em que você criou o pool de identidades da carga de trabalho autogerenciado.

  • SELECTOR: o seletor de recursos. Para uma lista de seletores compatíveis, consulte a seção Identificadores principais compatíveis. Por exemplo, subject/ns/NAMESPACE/sa/SERVICEACCOUNT seleciona uma conta de serviço específica do Kubernetes em um namespace específico.

A frota inteira compartilha um pool de identidade da carga de trabalho da frota. Assim, você pode conceder a aplicativos em qualquer lugar da frota, incluindo em outros projetos ou nuvens, acesso aos mesmos recursos sem precisar gerenciar esse acesso para cada cluster.

Sobre a semelhança de identidade

Assim como outros recursos ativados para a frota, a Federação de identidade de carga de trabalho da frota depende do princípio de semelhança, em que objetos do Kubernetes com o mesmo nome e namespace em clusters diferentes são tratados como a mesma coisa. Para saber mais sobre o princípio geral de semelhança em frotas, consulte Semelhança.

Com a federação de identidade da carga de trabalho para GKE de projeto único, a igualdade de identidade se aplica a todas as entidades que compartilham um identificador principal nesse projeto. No entanto, com a federação de identidade da carga de trabalho da frota, essa igualdade de identidade se aplica implicitamente a todas as entidades que compartilham um identificador principal em toda a frota, independentemente do projeto do cluster.

Por exemplo, considere um aplicativo com um back-end implantado em vários clusters na mesma frota. Se você conceder uma função a um identificador principal que seleciona a conta de serviço default do Kubernetes no namespace backend do Kubernetes, qualquer aplicativo nesse namespace que use essa conta de serviço terá o mesmo acesso.

Se a frota executar apenas clusters no projeto host da frota, as implicações de igualdade de identidade serão as mesmas da federação de identidade da carga de trabalho para GKE. No entanto, se a frota tiver clusters executados em outros projetos ou fora deGoogle Cloud, essa igualdade de identidade implícita será estendida a todos os clusters registrados na frota.

Semelhança de identidade em ambientes multilocatários ou de confiança mista

Por padrão, sua frota usa o pool de identidades de carga de trabalho gerenciado pelo Google do projeto host da frota para fornecer identidades a cargas de trabalho em toda a frota. Todos os clusters no projeto host da frota, incluindo clusters autônomos que não estão registrados na frota, usam esse pool de identidades de carga de trabalho. Em um ambiente de confiança mista em que esses clusters independentes executam cargas de trabalho com um modelo de confiança diferente, essa semelhança de identidade implícita pode resultar em acesso não intencional.

As frotas permitem gerenciar esse modelo multilocatário usando escopos de equipe e namespaces de frota. Com os escopos de equipe, é possível designar subconjuntos de recursos da frota, como clusters, para uso por equipes específicas na sua organização. Os namespaces da frota permitem definir namespaces do Kubernetes em escopos de equipe específicos, para que determinadas equipes só possam executar cargas de trabalho nos namespaces do escopo delas. Para detalhes, consulte Visão geral do gerenciamento de equipes de frota.

Se você usar escopos de equipe, poderá reduzir as complexidades de igualdade de identidade em frotas multitenant configurando seu próprio pool de identidades da carga de trabalho para clusters específicos na sua frota em vez do pool de identidades da carga de trabalho gerenciado pelo Google. Como resultado, os identificadores principais dessas cargas de trabalho são explicitamente diferentes dos identificadores principais dos clusters autônomos no projeto. Essa igualdade explícita de identidade oferece aos administradores mais controle sobre os limites em que a igualdade de identidade se aplica.

O modelo de igualdade de identidade na sua frota muda da seguinte maneira, dependendo se você usa apenas o pool de identidades da carga de trabalho gerenciado pelo Google ou configura um pool autogerenciado:

  • Igualdade implícita de identidade: todas as cargas de trabalho em uma frota usam o pool de identidades de carga de trabalho gerenciado pelo Google. Como resultado, toda carga de trabalho que compartilha o mesmo identificador principal também compartilha o mesmo acesso.

  • Semelhança explícita de identidade (prévia): você configura um pool de identidades de carga de trabalho autogerenciado para escopos de equipe na frota. O pool autogerenciado só fornece identidades para cargas de trabalho se você configurar um cluster para usar o pool autogerenciado em um namespace específico da frota. As cargas de trabalho executadas em outros namespaces e clusters do Kubernetes não podem usar o pool autogerenciado.

    Como resultado, a igualdade de identidade das cargas de trabalho que usam o pool autogerenciado é diferente da igualdade de identidade das cargas de trabalho que só podem usar o pool de identidades de carga de trabalho gerenciado pelo Google.

Quando usar pools de identidade da carga de trabalho autogerenciados

Use o pool de identidades da carga de trabalho gerenciado pelo Google se todos os clusters tiverem um nível de confiança semelhante em que as mesmas entidades implantam os mesmos aplicativos. Por exemplo, uma frota específica da equipe com um cluster em cada região que implanta um aplicativo replicado em cada cluster.

Recomendamos que você configure um pool de identidades de carga de trabalho autogerenciado para sua frota em cenários como os seguintes:

  • Vários níveis de confiança na frota: você executa clusters com vários níveis de confiança. Por exemplo, considere um cenário em que as equipes de finanças e de front-end têm clusters na mesma frota. Um pool de identidade da carga de trabalho autogerenciado ajuda a separar as concessões de acesso para cada equipe por namespace da frota. Isso significa que nem mesmo o administrador do cluster de front-end pode receber uma identidade no namespace da frota, a menos que tenha permissões explícitas.
  • Vários níveis de confiança no projeto: o projeto host da frota executa clusters autônomos que podem não ter o mesmo nível de confiança dos clusters da frota. Por padrão, esses clusters autônomos usam o pool de identidades de carga de trabalho gerenciado pelo Google do projeto host da frota. Os clusters da frota também usam esse pool de identidades da carga de trabalho, independente do projeto do cluster da frota. Definir um pool de identidades da carga de trabalho autogerenciado para a frota garante que as concessões de acesso no pool autogerenciado não concedam acesso involuntário aos clusters independente.
  • Práticas recomendadas para escopos de equipe: você já usa os recursos de gerenciamento de equipe da frota e quer implementar as práticas recomendadas para conceder acesso a cargas de trabalho. Ao definir um pool de identidades da carga de trabalho autogerenciado, é possível conceder acesso a cargas de trabalho em um namespace específico da frota em um escopo de equipe sem conceder esse acesso a outros escopos de equipe que executam cargas de trabalho nos mesmos clusters.

Como funciona a federação de identidade da carga de trabalho da frota

As seções a seguir descrevem como funciona a federação de identidade da carga de trabalho da frota, incluindo o fluxo de credenciais de autenticação e os identificadores principais do IAM compatíveis.

Fluxo de credenciais

Para permitir que aplicativos em um namespace específico se autentiquem usando a federação de identidade da carga de trabalho da frota, faça o seguinte:

  1. Implante um ConfigMap nesse namespace com as seguintes informações:

    • O pool de identidade da carga de trabalho e o provedor de identidade do cluster.
    • O caminho em cada pod em que o Kubernetes monta um token da conta de serviço. Esse token é um JSON Web Token (JWT) assinado.

    Esse ConfigMap funciona como o arquivo de credenciais padrão do aplicativo (ADC) para cargas de trabalho.

  2. Crie uma política de permissão do IAM que conceda acesso aGoogle Cloud recursos específicos ao identificador principal nos clusters, como uma conta de serviço no namespace.

  3. Verifique se a carga de trabalho no namespace tem as seguintes configurações na especificação do pod:

    • A variável de ambiente GOOGLE_APPLICATION_CREDENTIALS definida como o caminho de montagem do ConfigMap no pod.
    • Um volume projetado que contém o token da conta de serviço e o ConfigMap que você criou, montado no mesmo caminho especificado na variável de ambiente GOOGLE_APPLICATION_CREDENTIALS.
    • Uma montagem de volume no contêiner que faz referência ao volume projetado.

Quando a carga de trabalho faz uma chamada para a API Google Cloud , as seguintes etapas acontecem:

  1. As bibliotecas de autenticação do Google Cloud usam o Application Default Credentials (ADC) para encontrar credenciais. O ADC verifica o caminho que você especificou na variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para procurar um token de autenticação.
  2. A biblioteca de autenticação ADC usa os dados no ConfigMap para trocar o JWT da conta de serviço que você montou no pod por um token de acesso federado de curta duração do Serviço de token de segurança que faz referência ao identificador principal da carga de trabalho.
  3. O ADC inclui o token de acesso federado com a solicitação da API.
  4. A política de permissão do IAM autoriza o identificador principal a realizar a operação solicitada no recurso Google Cloud .

Identificadores principais com suporte para a federação de identidade da carga de trabalho da frota

A tabela a seguir descreve os seletores que podem ser usados em políticas de permissão do IAM para referenciar principais em frotas:

Tipo de identificador principal Sintaxe
Todos os pods que usam uma conta de serviço específica do Kubernetes Selecione a conta de serviço pelo nome: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Substitua:

  • PROJECT_NUMBER: o número numérico do projeto. Para conseguir o número do projeto, consulte Identificar projetos.
  • PROJECT_ID: o ID do projeto do Google Cloud .
  • NAMESPACE: o namespace do Kubernetes.
  • SERVICEACCOUNT: nome da conta de serviço do Kubernetes.
Selecionar a ServiceAccount pelo UID: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Substitua:

  • PROJECT_NUMBER: o número numérico do projeto. Para conseguir o número do projeto, consulte Identificar projetos.
  • PROJECT_ID: o ID do projeto da Flotta.
  • SERVICEACCOUNT_UID: o UID do objeto ServiceAccount no servidor da API.

A seguir