Acerca da federação de identidade da carga de trabalho da frota

Esta página descreve a federação de identidade da força de trabalho da frota, que é um mecanismo para autenticar pedidos de cargas de trabalho da frota para Google Cloud APIs. Nesta página, vai saber mais sobre a identidade idêntica para cargas de trabalho, como funciona a federação de identidade da carga de trabalho da frota e as boas práticas para a gerir em grande escala.

Esta página destina-se a administradores e operadores da plataforma, bem como a engenheiros de segurança que pretendem gerir a autorização de cargas de trabalho de forma mais eficiente em grande escala. Para saber mais acerca das funções de utilizador e das tarefas de exemplo a que fazemos referência na Google Cloud documentação, consulte Funções e tarefas comuns de utilizador do GKE.

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

Acerca das identidades de cargas de trabalho federadas no Google Cloud

A Federação de identidades de cargas de trabalho é uma Google Cloud funcionalidade que permite que as cargas de trabalho nos seus clusters sejam autenticadas no Google Cloud sem que tenha de transferir, rodar manualmente e, geralmente, gerir credenciais. Em alternativa, as cargas de trabalho autenticam-se através de tokens de curta duração gerados pelo Google Cloud.

A federação de identidades de cargas de trabalho para o GKE é uma implementação específica do GKE da federação de identidades de cargas de trabalho que fornece um conjunto do Workload Identity gerido pela Google ao nível do projeto a partir do qual as aplicações executadas em 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 membros da frota, independentemente de os clusters estarem em projetos diferentes ou fora do Google Cloud. Google CloudCom a federação de identidade da força de trabalho da frota, os clusters registados que têm a federação de identidade da força de trabalho ativada na respetiva associação à frota recebem identidades através de um conjunto do Workload Identity gerido pela Google ao nível da frota. Este conjunto partilhado permite-lhe configurar a autenticação para Google Cloud APIs e para outros serviços em toda a sua frota, mesmo em vários projetos.

A Federação do Workload Identity da frota também pode ser usada pelo agente Connect em alguns tipos de clusters para autenticar como parte da associação à frota e é necessária para usar algumas funcionalidades do GKE que funcionam em vários projetos, como a Cloud Service Mesh. Google Cloud

Acerca dos Workload Identity Pools

Um Workload Identity Pool é uma entidade que gere centralmente as identidades das suas aplicações. Quando ativa a Workload Identity Federation para o GKE nos seus clusters, o projeto do cluster recebe um Workload Identity Pool gerido pela Google com um nome fixo e específico do projeto. As aplicações nos seus clusters recebem identidades do conjunto do Workload Identity gerido pela Google para autenticar chamadas de API. Google Cloud O Workload Identity Pool gerido pela Google tem a sintaxe PROJECT_ID.svc.id.goog, onde PROJECT_ID é o ID do projeto do cluster.

Com a federação de identidades de cargas de trabalho da frota, o Workload Identity Pool gerido pela Google do projeto anfitrião da frota também é o Workload Identity Pool para todos os clusters que regista na frota, independentemente de esses clusters estarem noutros projetos ou fora do Google Cloud. Todos os clusters na frota usam o Workload Identity Pool, onde FLEET_HOST_PROJECT_ID é o ID do projeto do projeto anfitrião da frota.FLEET_HOST_PROJECT_ID.svc.id.goog

Se usar âmbitos da equipa, pode configurar opcionalmente um conjunto de identidades de carga de trabalho do IAM autogerido para os clusters usarem, além do conjunto gerido pela Google. Este pool autogerido oferece um controlo mais explícito sobre que cargas de trabalho recebem identidades específicas.

Cada aplicação na sua frota recebe uma identidade federada distinta do Workload Identity Pool da frota que a aplicação pode usar para autenticar no Google CloudGoogle Cloud e noutros serviços que desenvolve. As aplicações recebem um identificador principal que o IAM pode reconhecer. Este identificador usa a seguinte sintaxe:

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

Esta sintaxe tem os seguintes campos:

  • PREFIX: principal ou principalSet, consoante o tipo de recurso do Kubernetes que selecionar no campo SELECTOR.
  • FLEET_PROJECT_NUMBER: o número do projeto do projeto anfitrião da frota.

  • WORKLOAD_IDENTITY_POOL_NAME: o Workload Identity Pool para a sua frota. Este valor depende do Workload Identity Pool que configurou em cada cluster, da seguinte forma:

    • Workload Identity Pool gerido pela Google: FLEET_HOST_PROJECT_ID.svc.id.goog

    • Workload Identity Pool autogerido (pré-visualização): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, onde POOL_HOST_PROJECT_NUMBER é o número do projeto do projeto no qual criou o Workload Identity Pool autogerido.

  • SELECTOR: o seletor de recursos. Para ver uma lista dos seletores suportados, consulte a secção Identificadores principais suportados. Por exemplo, subject/ns/NAMESPACE/sa/SERVICEACCOUNT seleciona uma conta de serviço do Kubernetes específica num espaço de nomes específico.

Toda a frota partilha um conjunto do Workload Identity da frota para que possa conceder às aplicações em qualquer parte da frota, incluindo noutros projetos ou nuvens, acesso aos mesmos recursos sem ter de gerir esse acesso para cada cluster.

Acerca da identidade idêntica

Tal como outras funcionalidades ativadas para a frota, a Workload Identity Federation da frota baseia-se no princípio da igualdade, em que os objetos Kubernetes que têm o mesmo nome e espaço de nomes em diferentes clusters são tratados como a mesma coisa. Para saber mais acerca do princípio geral da igualdade nas frotas, consulte o artigo Igualdade.

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

Por exemplo, considere uma aplicação com um back-end implementado em vários clusters na mesma frota. Se conceder uma função a um identificador principal que selecione a conta de serviço do Kubernetes no espaço de nomes do Kubernetes, qualquer aplicação nesse espaço de nomes que use essa conta de serviço recebe o mesmo acesso.defaultbackend

Se a sua frota apenas executar clusters no projeto anfitrião da frota, as implicações de igualdade de identidade são as mesmas que para a federação de identidade da carga de trabalho para o GKE. No entanto, se a sua frota tiver clusters executados noutros projetos ou fora do Google Cloud, esta semelhança de identidade implícita estende-se a todos os clusters registados na frota.

Identidade igual em ambientes de vários inquilinos ou de confiança mista

Por predefinição, a sua frota usa o Workload Identity Pool gerido pela Google do projeto anfitrião da frota para fornecer identidades a cargas de trabalho na frota. Todos os clusters no projeto anfitrião da frota, incluindo clusters autónomos que não estão registados na frota, usam este Workload Identity Pool. Num ambiente de confiança mista em que estes clusters autónomos executam cargas de trabalho com um modelo de confiança diferente, esta igualdade de identidade implícita pode resultar num acesso não intencional.

As frotas permitem-lhe gerir este modelo multi-inquilino através de âmbitos de equipa e espaços de nomes de frotas. Os âmbitos de equipa permitem-lhe designar subconjuntos de recursos da frota, como clusters, para utilização por equipas específicas na sua organização. Os espaços de nomes da frota permitem-lhe definir espaços de nomes do Kubernetes em âmbitos de equipa específicos, para que determinadas equipas só possam executar cargas de trabalho nos espaços de nomes no âmbito da respetiva equipa. Para mais detalhes, consulte o artigo Vista geral da gestão da equipa de frotas.

Se usar âmbitos de equipa, pode mitigar as complexidades de identidade semelhantes em frotas multi-inquilinos configurando o seu próprio conjunto de identidades de carga de trabalho para clusters específicos na sua frota para usar em vez do conjunto de identidades de carga de trabalho gerido pela Google. Como resultado, os identificadores principais dessas cargas de trabalho são explicitamente diferentes dos identificadores principais dos clusters autónomos no projeto. Esta identidade explícita idêntica oferece aos administradores um maior controlo sobre os limites dentro dos quais a identidade idêntica se aplica.

O modelo de igualdade de identidade na sua frota muda da seguinte forma, com base no facto de usar apenas o conjunto de identidades do Workload Identity gerido pela Google ou configurar um conjunto de identidades do Workload Identity autogerido:

  • Identidade implícita igual: todas as cargas de trabalho numa frota usam o conjunto do Workload Identity gerido pela Google. Consequentemente, cada carga de trabalho que partilha o mesmo identificador principal partilha implicitamente o mesmo acesso.

  • Identidade explícita igual (pré-visualização): configura um Workload Identity Pool autogerido para âmbitos de equipa na frota. O conjunto autogerido só fornece identidades a cargas de trabalho se configurar um cluster para usar o conjunto autogerido para um espaço de nomes específico da frota. As cargas de trabalho executadas noutros espaços de nomes e clusters do Kubernetes não podem usar o pool autogerido.

    Como resultado, a igualdade de identidade das cargas de trabalho que usam o conjunto autogerido é diferente da igualdade de identidade das cargas de trabalho que só podem usar o Workload Identity Pool gerido pela Google.

Quando usar Workload Identity Pools autogeridos

Use o pool de identidades da carga de trabalho gerido pela Google se todos os clusters tiverem um nível de confiança semelhante em que as mesmas entidades implementam as mesmas aplicações. Por exemplo, uma frota específica da equipa com um cluster em cada região que implementa uma aplicação replicada em cada cluster.

Recomendamos que configure um Workload Identity Pool autogerido para a sua frota em cenários como os seguintes:

  • Vários níveis de confiança na frota: executa clusters com vários níveis de confiança. Por exemplo, considere um cenário em que as equipas financeiras e as equipas de front-end têm clusters na mesma frota. Um conjunto de identidades de carga de trabalho autogerido ajuda a separar as concessões de acesso para cada equipa por espaço de nomes da frota. Isto significa que mesmo o administrador do cluster do cluster de front-end não pode obter uma identidade no espaço de nomes da frota, a menos que tenha autorizações explícitas.
  • Vários níveis de confiança no projeto: o projeto anfitrião da frota executa clusters autónomos que podem não ter o mesmo nível de confiança que os clusters da frota. Por predefinição, estes clusters autónomos usam o Workload Identity Pool gerido pela Google do projeto anfitrião da frota. Os clusters da frota também usam este Workload Identity Pool, independentemente do projeto do cluster da frota. A definição de um Workload Identity Pool autogerido para a frota garante que as concessões de acesso no pool autogerido não concedem acesso involuntariamente aos clusters autónomos.
  • Práticas recomendadas para âmbitos de equipa: já usa funcionalidades de gestão de equipas de frotas e quer implementar práticas recomendadas para conceder acesso a cargas de trabalho. A definição de um conjunto de identidades do workload autogerido permite-lhe conceder acesso a workloads num espaço de nomes de frotas específico num âmbito de equipa sem conceder esse acesso a outros âmbitos de equipa que executam workloads nos mesmos clusters.

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

As secções seguintes descrevem como funciona a Workload Identity Federation da frota, incluindo o fluxo de credenciais de autenticação e os identificadores de principais do IAM suportados.

Fluxo de credenciais

Para permitir que as aplicações num espaço de nomes específico façam a autenticação através da Federação de identidades de carga de trabalho da frota, faça o seguinte:

  1. Implemente um ConfigMap nesse espaço de nomes com as seguintes informações:

    • O Workload Identity Pool e o fornecedor de identidade para o seu cluster.
    • O caminho em cada Pod no qual o Kubernetes monta um token ServiceAccount. Este token é um símbolo da Web JSON (JWT) assinado.

    Este ConfigMap funciona como o ficheiro de credenciais predefinidas da aplicação (ADC) para cargas de trabalho.

  2. Crie uma política de autorização da IAM que conceda acesso a Google Cloud recursos específicos ao identificador principal do principal nos seus clusters, como uma ServiceAccount no espaço de nomes.

  3. Certifique-se de que a sua carga de trabalho no espaço de nomes tem as seguintes configurações na especificação do pod:

    • A variável de ambiente GOOGLE_APPLICATION_CREDENTIALS definida para o caminho de montagem do ConfigMap no pod.
    • Um volume projetado que contém o token ServiceAccount e o ConfigMap que criou, montado no mesmo caminho que especifica na variável de ambiente GOOGLE_APPLICATION_CREDENTIALS.
    • Uma montagem de volume no contentor que faz referência ao volume projetado.

Quando a carga de trabalho faz uma Google Cloud chamada API, ocorrem os seguintes passos:

  1. As bibliotecas de autenticação Google Cloud usam as credenciais padrão da aplicação (ADC) para encontrar credenciais. O ADC verifica o caminho que especificou na variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para procurar um token de autenticação.
  2. A biblioteca de autenticação da ADC usa os dados no ConfigMap para trocar o JWT da conta de serviço que montou no pod por um token de acesso federado de curta duração do Security Token Service que faz referência ao identificador principal da carga de trabalho.
  3. O ADC inclui o token de acesso federado com o pedido de API.
  4. A política de autorização da IAM autoriza o identificador principal a executar a operação pedida no Google Cloud recurso.

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

A tabela seguinte descreve os seletores que pode usar nas políticas de autorização do IAM para fazer referência a diretores em frotas:

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

Substitua o seguinte:

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

Substitua o seguinte:

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

O que se segue?