Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Workload Identity no GKE: como analisar erros comuns de configuração

By Eyal ZekariaNov 8, 20225 min read

Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.

Conheça o GKE Workload Identity Analyzer, ferramenta criada pela DoiT para analisar workloads em execução no GKE e garantir que o Workload Identity esteja configurado corretamente.

workload-identity-for-gke (1)

O GKE Workload Identity Analyzer garante que o Workload Identity esteja configurado corretamente

Se você usa o Google Kubernetes Engine (GKE) e seus workloads se comunicam com outros serviços dentro do Google Cloud, é bem provável que você já esteja usando o Workload Identity. E se ainda não usa, deveria. O Google recomenda o Workload Identity para que workloads em execução no Google Kubernetes Engine (GKE) acessem os serviços do Google Cloud de forma segura e gerenciável.

Alternativas ao Workload Identity

Outras opções (um tanto legadas) para autenticação entre o GKE e o Google Cloud incluem:

  • usar a conta de serviço padrão do Compute Engine, que normalmente concede um escopo amplo demais e não pode ser personalizada por workload;
  • fornecer secrets de contas de serviço aos seus workloads, o que representa um risco de segurança, já que essas chaves são credenciais de longa duração e exigem cuidados e rotação periódica para seguir as boas práticas de segurança.

Como o Workload Identity funciona

O Workload Identity não traz nenhuma dessas preocupações: ele é configurado por workload e dispensa o gerenciamento ou a injeção de secrets no seu workload.

Na prática, ele funciona criando uma relação entre uma Kubernetes Service Account (KSA) e uma Google Service Account (GSA). A KSA identifica o seu workload em execução no GKE como usuário da GSA, e a GSA, por sua vez, recebe os acessos necessários aos recursos do Google Cloud. Esse acesso pode ser tão amplo ou tão restrito quanto o seu workload exigir — por exemplo, um workload que precise acessar todos os tópicos do PubSub em um projeto, em comparação com outro que precise acessar apenas um (ou alguns).

As vantagens do Workload Identity são óbvias, mas usá-lo exige um trabalho extra de configuração, que pode confundir um pouco no começo.

Erros de configuração podem surgir em vários elos da cadeia de autenticação entre um Pod no GKE e um serviço em um projeto do GCP — o que torna a investigação bem trabalhosa.

O que o GKE Workload Identity Analyzer faz

Foi pensando nisso que a DoiT criou o GKE Workload Identity Analyzer. A ferramenta de linha de comando Workload Identity (WI) Analyzer recebe o nome de um pod como argumento e roda checagens de configuração para confirmar que o WI está configurado corretamente para o seu workload. Ela verifica:

  • se o Workload Identity está habilitado no cluster GKE;
  • se o Pod tem .spec.serviceAccountName configurado;
  • se a KSA (configurada na etapa anterior) existe;
  • se a KSA está anotada corretamente com uma GSA;
  • se a GSA (configurada na etapa anterior) existe no projeto;
  • se a KSA tem roles/iam.workloadIdentityUser na GSA.

Por fim, a ferramenta verifica e lista as roles de IAM que a GSA possui no projeto (vale lembrar que ela não verifica roles de IAM concedidas em escopo mais restrito, como recursos específicos do GCP — tópico do PubSub, instância do CloudSQL etc.).

A execução leva menos de 10 segundos e pode poupar muito tempo de inspeção de recursos no console ou de execução de comandos no terminal.

A ferramenta foi escrita em Python e publicada no PyPI. A instalação é simples, com o PIP:

$ pip install wi-analyzer

Executando o GKE Workload Identity Analyzer

Os pré-requisitos para executá-la são:

  • gcloudcli instalado e configurado;
  • Application Default Credentials geradas via gcloud;
  • kubectl instalado e configurado com acesso ao cluster.

Vale destacar que a ferramenta extrai algumas informações do seu contexto atual do kubeconfig. Ela também espera o nome padrão gerado para um cluster GKE ao buscar credenciais (no formato gke_<GCP_PROJECT_ID>__<CLUSTER_NAME>).

Como alternativa, basta passar argumentos para configurar o ID do projeto GCP, a localização e o nome do cluster.

Com tudo configurado, é só rodar a ferramenta no terminal:

$ wi-analyzer --help
usage: wi-analyzer [-h] [-n NAMESPACE] [-d] pod
GKE Workload Identity Analyzer
positional arguments:
pod Kubernetes Pod name to check
options:
-h, --help show this help message and exit
-n NAMESPACE, --namespace NAMESPACE
Kubernetes Namespace to run in
-p PROJECT, --project PROJECT
GCP Project holding the cluster
-l LOCATION, --location LOCATION
The GCP location of the cluster
-c CLUSTER, --cluster CLUSTER
The name of the cluster
-d, --debug Enable debug logging

Imagine, por exemplo, que eu estava seguindo a documentação para configurar meu workload com WI e, sem querer, pulei uma etapa simples. A saída da ferramenta pode ajudar a identificar isso:

$ wi-analyzer demo-pod
Check results
---------------------------
V=Passed, X=Failed, -=Skipped
[V] GCP project and GKE info determined from current context
[V] Namespace passed as argument,or determined from current context
[V] Workload Identity enabled on GKE Cluster
[V] Pod found in current context
[V] GKE Node found in the cluster
[V] Workload Identity enabled on Node Pool
[V] KSA found in the cluster
[X] KSA Workload Identity annotation set correctly
[-] GSA found in GCP project
[-] GSA is enabled
[-] GSA has Workload Identity users configured
[-] GSA does not have KSA as a Workload Identity user
GKE cluster info
---------------------------
Cluster: "projects/test-eyal/locations/europe-west1-b/clusters/playground"
Workload: "demo/demo-pod" running on Node: "gke-playground-nodepool-1f1ace09-96kr"
KSA name: "demo-ksa"
Google Service Account info
---------------------------
Google Service Account information could not be determined, fix previous issues

Como a saída indica, faltava a anotação de WI na KSA. Depois de corrigir, ao rodar a ferramenta de novo, devemos ver apenas checagens bem-sucedidas e a visão completa:

$ wi-analyzer demo-pod
Check results
---------------------------
V=Passed, X=Failed, -=Skipped
[V] GCP project and GKE info determined from current context
[V] Namespace passed as argument,or determined from current context
[V] Workload Identity enabled on GKE Cluster
[V] Pod found in current context
[V] GKE Node found in the cluster
[V] Workload Identity enabled on Node Pool
[V] KSA found in the cluster
[V] KSA Workload Identity annotation set correctly
[V] GSA found in GCP project
[V] GSA is enabled
[V] GSA has Workload Identity users configured
[V] GSA does not have KSA as a Workload Identity user
GKE cluster info
---------------------------
Cluster: "projects/test-eyal/locations/europe-west1-b/clusters/playground"
Workload: "demo/demo-pod" running on Node: "gke-playground-nodepool-1f1ace09-96kr"
KSA name: "demo-ksa"
Google Service Account info
---------------------------
Google Service Account: "projects/test-eyal/serviceAccounts/[email protected]"
Has the following Workload Identity Users:
serviceAccount:test-eyal.svc.id.goog[demo/demo-ksa]
GSA: "[email protected]" has the following roles in project "test-eyal":
roles/cloudsql.client
Workload Identity configured properly - check if any IAM roles are missing from the list above

No momento, a ferramenta dá suporte apenas ao GKE Standard, mas o suporte ao Fleet Workload Identity (GKE WI para Anthos) já está no roadmap. Os testes em clusters Anthos multicloud já começaram, mas vão exigir mudanças fundamentais na ferramenta. Fique de olho!

Encontrou algum problema na ferramenta? Tem ideias de novas funcionalidades?

Fale com a gente, aqui nos comentários ou abrindo uma issue no repositório do GitHub.