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.
A Identidade de carga de trabalho substitui a necessidade de usar Ocultação de metadados. Os metadados confidenciais protegidos pela ocultação de metadados também são protegidos pela Identidade da carga de trabalho.
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 com o seguinte formato:
PROJECT_ID.svc.id.goog
O pool de identidades de carga de trabalho fornece um formato de nomenclatura que permite que o IAM entenda e confie nas credenciais da conta de serviço do Kubernetes. A ativação da Identidade da carga de trabalho não concede às cargas de trabalho permissões do IAM por padrão.
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.
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:
|
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. |
Restrições de Identidade da carga de trabalho
Não é possível alterar o nome do pool de identidades da carga de trabalho que o GKE cria para o projeto do Google Cloud.
Quando o GKE ativa o servidor de metadados do GKE em um pool de nós, os pods não podem mais acessar o servidor de metadados do Compute Engine. Em vez disso, o servidor de metadados do GKE intercepta solicitações feitas desses pods para endpoints de metadados, com exceção dos pods em execução na rede do host.
O servidor de metadados do GKE leva alguns segundos para começar a aceitar solicitações em um pod recém-criado. Portanto, as tentativas de autenticação usando a Identidade da carga de trabalho nos primeiros segundos da vida de um pod podem falhar. Tentar novamente a chamada resolverá o problema. Consulte Solução de problemas para mais detalhes.
Os agentes integrados de geração de registros e monitoramento do GKE continuarão a usar a conta de serviço do nó.
A Identidade da carga de trabalho requer a configuração manual para que o Cloud Run para Anthos continue lançando métricas de solicitação.
A Identidade da carga de trabalho define um limite de 200 conexões com o servidor de metadados do GKE para cada nó, a fim de evitar problemas de memória. Expirações de tempo limite podem acontecer se os nós excederem esse limite.
A Identidade da carga de trabalho para nós do Windows Server está disponível nas versões do GKE 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 e posteriores.
O servidor de metadados do GKE usa recursos de memória proporcionalmente ao número total de contas de serviço do Kubernetes no seu cluster. Se o cluster tiver mais de 3.000 contas de serviço do Kubernetes, o kubelet poderá encerrar os pods do servidor de metadados. Para mitigações, consulte Solução de problemas.
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
- Saiba como ativar e configurar a Identidade da carga de trabalho.
- Saiba mais sobre o servidor de metadados do Compute Engine.