Workload Identity Federation no GCP: como eliminar chaves de longa vida em produção

Toda vez que um time conecta uma nova ferramenta de CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps → ou dá acesso de terceiro a um projeto GCP, a receita costuma ser a mesma: criar uma service account no IAM, baixar uma chave JSON e colar esse arquivo como secret em algum lugar. Funciona, mas deixa um rastro de credenciais de longa vida espalhadas por secret stores, variáveis de ambiente e, no pior caso, no controle de versão.

Em artigo publicado no InfoQ, o engenheiro Shijin Nair descreve como sua organização atacou esse problema com Workload Identity Federation (WIF), o recurso do Google Cloud que permite a workloads externos autenticarem sem chaves permanentes. O texto não é uma introdução teórica: é um relato de adoção em escala, com os números, as decisões de arquitetura e um erro de escopo que vale conhecer antes de replicar.

O problema das chaves JSON

É possível configurar chaves de service account com data de expiração e, por segurança, você deveria. Mas isso cria um custo operacional próprio: a cada expiração é preciso gerar uma nova chave, encontrar todos os sistemas e times que usam a antiga e distribuir a nova. Segundo Nair, esse overhead é grande o suficiente para que muitos times simplesmente pulem a expiração e deixem as chaves abertas por tempo indeterminado, uma solução bem pior.

O agravante é o raio de impacto. Se uma chave vaza, você em geral só descobre o alcance depois de vasculhar logs de auditoria, e isso depende de o audit logging estar habilitado de antemão.

O que muda de modelo mental

O ponto central do artigo é uma troca de conceito:

Chaves são segredos que você gerencia, enquanto identidades federadas são relações de confiança que você configura.

Shijin Nair, InfoQ

Em vez de entregar uma credencial a um sistema externo, você declara antecipadamente ao GCP quais provedores de identidade externos confia e sob quais condições. Quando o workload externo precisa de acesso, ele apresenta seu próprio token nativo ao Security Token Service (STS) do GCP. Se o token passar na validação, o GCP emite um access token de curta duração. O job roda, o token expira, nada fica armazenado e nada precisa ser rotacionado.

Os três componentes obrigatórios

WIF sempre segue o mesmo modelo de três partes, independentemente do provedor:

A cerimônia dos três objetos parecia excessiva à primeira vista, escreve Nair, mas ele conclui que a cerimônia é o próprio ponto: a relação de confiança é declarada uma vez e nunca mais manuseada.

O modelo não é exclusivo do GCP. O Microsoft Entra Workload ID implementa a mesma ideia no Azure com credenciais federadas baseadas em OIDC. O que muda entre nuvens é a sintaxe. As condições de atributo em CEL (Common Expression Language) descritas aqui são específicas da implementação do Google.

A adoção: mandato na criação, não migração

A decisão mais interessante do relato é o que a organização não fez. Ela não migrou as chaves existentes. O ambiente tinha centenas de chaves de service account sem expiração, algumas com anos de idade. Retrofitar essas chaves exigiria coordenar todos os times e sistemas que guardavam cópias, com risco de indisponibilidade a cada passo e sem forma limpa de provar que uma chave estava realmente morta.

Em vez disso, a linha foi traçada no ponto de criação. Como parte de uma iniciativa de modernização, WIF passou a ser obrigatório para todo novo projeto GCP, imposto no provisionamento e não deixado a critério de cada time. Nenhum projeto novo recebeu chave JSON; os deploys passaram a rodar por pipelines Harness com identidade federada.

O resultado, segundo o texto: em seis meses, mais de 120 projetos autenticavam dessa forma. As chaves legadas não sumiram, mas pararam de se multiplicar, transformando um problema que só crescia em um problema fixo e decrescente.

A condição de atributo é o portão de segurança

O erro mais perigoso ao configurar WIF é omitir a attribute condition. Sem ela, qualquer token válido do issuer passa, o que é amplo demais para produção. A condição é uma expressão CEL que filtra quais identidades entram de fato.

Num caso Harness descrito por Nair, a condição era:

attribute.account_id == "abcdrfghijklmnop" &&
attribute.organization_id == "my_org_platform"

Com isso, mesmo um JWT Harness válido vindo de outra conta seria rejeitado. O autor alerta para uma armadilha específica: em contas Harness com múltiplas organizações, filtrar só por account_id e esquecer o organization_id é permissivo demais.

GitHub Actions para GCP na prática

O caso mais comum é o GitHub Actions, que já entrega um token OIDC automaticamente a cada job, contendo repositório, branch e workflow. Não há configuração do lado do GitHub. Do lado do GCP, cria-se o pool e o conector:

gcloud iam workload-identity-pools create github-pool \
  --location="global" \
  --project=YOUR_PROJECT

gcloud iam workload-identity-pools providers create-oidc github-connector \
  --location="global" \
  --workload-identity-pool=github-pool \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --attribute-condition="assertion.repository=='your-org/your-repo'" \
  --project=YOUR_PROJECT

Em seguida, o binding com a service account e, no workflow, a permissão id-token: write mais a action google-github-actions/auth@v2. Nenhum secret fica armazenado no GitHub e o token expira com o fim do run.

O caso AWS: como o GCP valida um token que não é OIDC

A parte que mais surpreende, segundo o artigo, é a integração com a AWS, que não usa OIDC para seus tokens de workload e sim seu próprio formato baseado em AssumeRole. Aqui a âncora de confiança é um AWS account ID, não um issuer URL, e o provider usa um tipo dedicado.

O fluxo por baixo dos panos vale entender:

1. O workload envia ao STS do GCP suas credenciais AWS empacotadas como uma requisição assinada ao GetCallerIdentity.
2. O GCP faz a chamada GetCallerIdentity à própria AWS usando essa requisição assinada, perguntando se o token é real.
3. A AWS valida a assinatura internamente e responde com o ARN da IAM role e o account ID.
4. O GCP compara o account ID retornado com o configurado no provider. Bateu, o token é genuíno; não bateu, é rejeitado.

A assinatura dessa resposta só pode ser produzida pela própria AWS, o que impede falsificação de fora.

O que isso muda para quem constrói software no Brasil

Para times brasileiros que rodam infraestrutura em GCP, o relato é acionável em dois níveis. No técnico, o modelo de três partes e os comandos gcloud funcionam igual em qualquer região, e o padrão de mandato na criação de projeto é replicável em qualquer estratégia de landing zone. No estratégico, a lição de tratar chaves legadas como um conjunto fixo e decrescente, em vez de encarar uma migração arriscada, é útil para quem tem um passivo de credenciais e nunca acha janela para mexer nele.

O que fica em aberto no artigo é justamente o destino das chaves antigas: elas param de crescer, mas continuam lá. E há uma escolha de arquitetura que o autor faz de forma diferente do padrão recomendado pelo Google (impersonation em vez de acesso direto) cujo detalhamento vale a leitura da fonte completa no InfoQ antes de decidir o desenho para o seu ambiente.

Fonte: InfoQ