Um guia técnico publicado pelo freeCodeCamp demonstra como autenticar pods Kubernetes on-premises no Google Cloud Platform sem usar chaves de serviço de longa duração. A solução utiliza Workload Identity Federation para que pods apresentem tokens JWT assinados pelo cluster e recebam credenciais temporárias do GCP, eliminando um dos riscos mais comuns em arquiteturas híbridas.
O problema: chaves de serviço que nunca expiram
Ambientes híbridos que combinam infraestrutura on-premises com serviços cloud enfrentam um dilema recorrente: como conceder acesso seguro aos recursos na nuvem sem distribuir credenciais estáticas. O padrão mais comum, criar uma Service Account no GCP e exportar sua chave JSON, resolve o problema imediato, mas introduz riscos significativos.
Chaves de serviço não expiram por padrão, não geram logs detalhados de uso e, quando comprometidas, concedem acesso irrestrito até serem manualmente revogadas. Em organizações com múltiplos clusters e dezenas de workloads consumindo serviços cloud, o gerenciamento dessas chaves se torna uma superfície de ataque em crescimento constante.
Como Workload Identity Federation resolve isso
A abordagem proposta substitui chaves estáticas por um fluxo de autenticação federada. O processo funciona assim: cada pod Kubernetes recebe um token JWT assinado criptograficamente pelo servidor de API do cluster. Esse token é apresentado ao Security Token Service (STS) do GCP, que valida a assinatura contra o JWKS (JSON Web Key Set) público do cluster e retorna um token de acesso temporário, tipicamente válido por uma hora.
O resultado prático é que nenhuma credencial de longa duração precisa ser armazenada nos nós, nos pods ou em ConfigMaps. Os tokens expiram automaticamente, são auditáveis e podem ser revogados a qualquer momento simplesmente removendo o binding de IAM.
Controle granular com CEL e automação com Kyverno
O guia detalha o uso de Common Expression Language (CEL) para implementar controle de acesso fino no nível do identity pool do GCP. Com CEL, é possível restringir quais namespaces, ServiceAccounts ou até clusters específicos podem assumir determinadas identidades na nuvem. Isso evita que um pod comprometido em um namespace de desenvolvimento consiga escalar privilégios para acessar recursos de produção.
Para eliminar configuração manual em cada deployment, a solução utiliza Kyverno com um único ClusterPolicy que injeta automaticamente a configuração de credenciais federadas em todos os pods elegíveis. Novos workloads já nascem configurados, sem exigir conhecimento do fluxo de autenticação por parte do desenvolvedor.
Motivação: a economia das GPUs mudou o jogo
O artigo contextualiza a demanda por cloud híbrida a partir da escassez e do custo de GPUs. Organizações mantêm infraestrutura on-premises para compute genérico, onde o custo por ciclo é menor, e utilizam cloud para workloads de IA e machine learning que exigem aceleradores. Essa divisão econômica torna a integração segura entre os dois ambientes uma necessidade operacional, não uma escolha arquitetural teórica.
O cenário é familiar para empresas brasileiras de médio porte: o data center próprio ou colocation continua viável para aplicações do dia a dia, mas projetos de IA e análise de dados massivos demandam recursos de cloud pública. Conectar esses dois mundos de forma segura e auditável é o desafio central.
Aplicabilidade prática
A arquitetura descrita é agnóstica quanto à distribuição Kubernetes. Funciona com k3s, kubeadm, Rancher, vCluster ou qualquer cluster que exponha um endpoint OIDC. O guia inclui uma seção específica sobre como usar vCluster para validar o setup em ambiente de prova de conceito antes de levar para produção, além de artefatos Terraform prontos para provisionar os recursos GCP necessários.
Para equipes que já operam Kubernetes on-premises e consomem serviços de cloud pública, a migração para Workload Identity Federation pode ser feita de forma incremental, workload por workload, sem interromper operações existentes.
O que observar daqui
O padrão de federação de identidade está se consolidando como prática recomendada em todas as clouds. A AWS tem uma implementação análoga via IRSA (IAM Roles for Service Accounts) e o Azure oferece Workload Identity para AKS. Para quem opera em ambientes multi-cloud ou híbridos, investir nesse modelo agora simplifica a postura de segurança e elimina uma classe inteira de incidentes relacionados a credenciais estáticas comprometidas.