Visão geral da Identidade da carga de trabalho

A Identidade da carga de trabalho permite atribuir identidades e autorizações detalhadas e distintas para cada aplicativo no cluster. A Identidade da carga de trabalho é a maneira recomendada para que aplicativos executados no GKE no Azure acessem os serviços do Azure e do Google Cloud.

Todos os clusters do GKE têm a identidade da carga de trabalho ativada.

Contas de Serviço Kubernetes

A identidade da carga de trabalho implementa a federação de identidades ou delega a confiança ou os papéis a um provedor externo. Cada cluster tem um provedor OpenID Connect (OIDC) integrado. Quando um pod é executado no cluster, ele é executado usando uma conta de serviço do Kubernetes. O pod pode ser configurado para receber um token com credenciais de curta duração para a conta de serviço do Kubernetes usando um Volume de token vinculado da conta de serviço.

Provedores do OpenID Connect

Cada cluster pode atuar como um provedor do OpenID Connect (OIDC). Com esse provedor, é possível fornecer credenciais de conta de serviço do Kubernetes para serviços compatíveis com federação de identidade usando o OIDC.

O URI do emissor desse provedor também serve como um endpoint de descoberta do OIDC. Os serviços podem usar esse endpoint de descoberta para receber o conjunto de chaves da Web JSON (JWKS, na sigla em inglês), que fornece informações de chave pública para verificar as credenciais da conta de serviço do Kubernetes.

Pools e provedores de identidade do Google Cloud IAM

O Google Cloud IAM é compatível com a federação de identidades usando o OIDC. Todos os clusters do GKE são configurados como provedores de identidade no pool de identidades da carga de trabalho PROJECT_ID.svc.id.goog.

Para ver o nome do pool de identidades e provedores de carga de trabalho, consulte Usar a identidade da carga de trabalho com o Google Cloud.

Alternativas à Identidade da carga de trabalho

Há métodos alternativos para acessar serviços do GKE no Azure. Não recomendamos os métodos a seguir devido a complicações.

  1. Exportar credenciais e armazenená-las como secrets do Kubernetes. Nesse caso, você precisa alternar as credenciais armazenadas manualmente no IAM do Azure e no cluster. Além disso, se um invasor roubar credenciais, ele poderá explorá-las.

  2. Anexar credenciais às instâncias subjacentes dos pools de nós. Nesse caso, todas as cargas de trabalho em execução no mesmo nó compartilham as credenciais, o que pode resultar em um conjunto maior de permissões do que as cargas de trabalho podem. Para bloquear o acesso às permissões de uma instância, os clusters do GKE bloqueiam o acesso de um pod para o serviço de metadados da instância.

A seguir