GKE Workload Identity virou Workload Identity Federation — o que mais mudou?

O WIF é um recurso pensado para conectar sistemas de identidade externos ao IAM do Google Cloud. Ele permite que organizações estendam, de forma transparente, sua infraestrutura de identidade já existente — como Active Directory, AWS, Okta e outros — aos recursos do Google Cloud.

Ao estabelecer relações de confiança entre provedores de identidade externos (IdP) e o IAM do Google Cloud, o WIF permite que usuários e aplicações autenticados em sistemas que não são do GCP acessem recursos do GCP usando suas identidades atuais.

Para criar essa relação de confiança, primeiro você cria um Workload Identity Pool para gerenciar as identidades externas e, em seguida, adiciona Workload Identity Providers ao pool, cada um descrevendo a relação entre o seu IdP e o GCP.

Depois de estabelecida, um token de credencial do seu IdP pode ser verificado pelo Security Token Service do Google e trocado por um token federado usado para autenticar no GCP.

No Workload Identity Federation for GKE (antes chamado apenas de Workload Identity), o Google gerencia o pool e o provider para você.

Cada projeto do GCP tem um único pool fixo (PROJECT_ID.svc.id.goog) e, quando o recurso é habilitado em um cluster GKE, ele é registrado como um identity provider nesse pool.

O GKE metadata server é então implantado automaticamente em todos os nós do cluster como um DaemonSet. Entre outras funções, ele intercepta as requisições vindas dos seus workloads e responde com o token correto para a service account que o workload está configurado para impersonar.

É justamente esse o objetivo do recurso: permitir que seus workloads no GKE acessem recursos no GCP sem precisar passar credenciais explícitas, e sem nem mesmo recorrer à IAM Service Account do nó.

O primeiro passo é habilitar o WIF no seu cluster GKE e nos node pools, caso ainda não tenha feito isso, mas isso já está bem documentado e foge do escopo deste post.

Feito isso, você precisará criar uma Kubernetes Service Account (KSA) para o seu workload usar (configurando-a no spec do Pod).

A partir daí, com o Workload Identity (WI), você pode conceder permissões IAM do GCP aos seus workloads de duas formas:

Via impersonação de Google IAM Service Accounts

Esse era o caminho padrão e único de configurar o WI até pouco tempo atrás. Hoje, está documentado como a forma alternativa.

Em resumo, é preciso criar uma Google Service Account (GSA) e conceder a ela todas as permissões IAM necessárias para o seu workload. Depois, é necessário criar um binding entre a GSA e a KSA, tornando a KSA um roles/iam.workloadIdentityUser da GSA, além de anotar a KSA adequadamente.

Via identificadores de IAM principal

Esse é um recurso importante e uma mudança recente, como mencionado na introdução. Recursos do Kubernetes podem ser referenciados diretamente em políticas IAM como principals.

Você pode referenciar a sua KSA pelo nome (para identity sameness) ou pelo UID (disponível no spec da KSA depois da criação).

Dá até para apontar para todos os pods de um cluster, caso exista alguma permissão IAM comum a todos os seus workloads.

Fonte: https://twitter.com/_techcet_/status/1773865010651173293

Como mostra a tabela acima, a configuração ficou bem mais simples com a possibilidade de referenciar recursos do Kubernetes como IAM principals.

Em vez de gerenciar uma GSA adicional e lembrar de dar permissão à KSA para impersoná-la (um passo que costuma ser esquecido), agora você consegue conceder os IAM roles necessários diretamente à KSA. Também não é mais preciso anotar a KSA com o nome da GSA — outro ponto que era facilmente mal configurado ou esquecido.

Poder referenciar uma KSA pelo UID, em vez de pelo nome, é uma ótima novidade e reduz o risco de conceder acesso por engano a workloads indesejados via identity sameness. Por outro lado, identity sameness pode ser uma vantagem quando usado corretamente, e isso continua viável nas duas versões da configuração.

Além disso, a possibilidade de referenciar todos os pods de um cluster como um IAM principal set é um recurso útil e dá mais flexibilidade. Tenho certeza de que, nos próximos meses, veremos suporte a mais tipos de recursos do Kubernetes como IAM principals (namespaces seriam uma adição e tanto).

Uma limitação ao usar IAM principals é que ainda existe um conjunto de serviços que não têm suporte ou estão em preview. Se você usa o WI hoje para acessar algum desses serviços, vai precisar segurar a atualização da configuração.

A boa notícia é que você não é obrigado a migrar — o caminho via GSA impersonation continua suportado e não acredito que vá sumir tão cedo.

Mesmo assim, usar IAM principals simplifica a configuração e traz alguns benefícios extras, como descrito na seção anterior, então recomendo adotar sempre que possível.

Qual é a forma menos friccional de migrar seus workloads da configuração atual para IAM principals?

Supondo que você esteja usando o Workload Identity para acessar recursos do GCP, você terá uma GSA com as permissões IAM necessárias e uma KSA com o IAM role Workload Identity User sobre essa GSA.

Por fim, sua KSA estará anotada apontando para a GSA, por exemplo:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com
  ...

Vamos ver se conseguimos fazer uma atualização "sem downtime" da configuração de WI.

Primeiro, vamos subir um pod que usa essa KSA para rodar alguns testes

$ echo 'apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
spec:
  serviceAccountName: <KSA_NAME>
  containers:
  - image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    name: workload-identity-test' | kubectl apply -f -

Quando o pod estiver pronto e rodando, podemos entrar nele com exec

$ kubectl exec -ti token-test -- bash

De dentro do pod, podemos fazer uma requisição ao metadata server e ver qual identidade o nosso pod está usando

root@token-test:/# curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
{"aliases":["default"],"email":"<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com","scopes":["https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/userinfo.email"]}

Pelo campo email da resposta, dá para ver que a nossa identidade é a GSA que a nossa KSA está configurada para usar (via anotação na KSA).

O que aconteceria se removêssemos essa anotação da KSA?

# isso é executado fora do pod
$ kubectl annotate serviceaccount <KSA_NAME> iam.gke.io/gcp-service-account-

Vamos repetir a requisição

root@token-test:/# curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
{"aliases":["default"],"email":"<PROJECT_ID>.svc.id.goog","scopes":["https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/userinfo.email"]}

Como dá para ver, a nossa identidade muda na hora para o Workload Identity Pool do projeto. Isso significa que migrar de GSA impersonation para IAM principal binding deve funcionar sem precisar nem reiniciar os pods (vale ressaltar que pode haver clients que exijam reinício para passar a usar a nova identidade).

Considerando que sua KSA continua anotada com a GSA e o workload está funcional:

1. Crie a política IAM para conceder os IAM roles necessários diretamente à KSA (os mesmos roles concedidos à sua GSA)
2. Remova a anotação de WI da KSA. A partir desse momento, o pod deve passar imediatamente a usar as permissões concedidas ao principal da KSA (se aparecer algum erro, um restart do pod costuma resolver)
3. Depois de confirmar que tudo está funcionando, dá para limpar a GSA — agora redundante — e garantir que seu IaC e seus manifests estejam todos atualizados