Resumo

  • O draft-ietf-wimse-workload-identity-practices-06 descreve credenciais emitidas pela plataforma, com vida curta e audiência limitada, em lugar de segredos estáticos geridos pela aplicação.
  • Uma credencial válida não prova sozinha a instância exata, a exclusividade da chave, a remoção de cópias antigas, a autorização da operação, a execução do pedido ou o resultado pretendido.

O avanço e o limite

O Workload Identity Practices começa com um problema operacional: senhas, API keys e segredos OAuth embutidos precisam ser distribuídos e rotacionados, e continuam úteis ao atacante enquanto forem válidos. A alternativa é a plataforma observar a carga, emitir uma credencial e permitir sua troca por outra adequada ao recurso externo.

Kubernetes, SPIFFE, provedores de nuvem, CI/CD e service meshes implementam o padrão de modos diferentes. O ponto comum é reduzir a gestão direta de segredos, não declarar que toda confiança passou a caber em um token.

O estado do documento também limita a leitura. O Datatracker mostra a revisão 06 como Internet-Draft ativo, pretendido como Informational, submetido ao IESG e em “AD Evaluation::Revised I-D Needed”. Não é RFC, selo de conformidade nem evidência de implantação.

Primeiro recibo: o bootstrap

A identidade nasce daquilo que a plataforma observou. Pode ser host, processo, UID, metadado do kernel, cgroup ou rótulo do orquestrador. SPIFFE evita pedir um segredo prévio à Workload API: identifica o chamador pelo contexto. Isso resolve o círculo de precisar de credencial para obter credencial, mas não torna o seletor perfeito. Um identificador de máquina compartilhada é menos específico que um vínculo ao processo e à instância.

O recibo inicial deve registrar emissor, atributos observados, versões do attestor e da política, horário e decisão. A assinatura posterior não recupera inputs que nunca foram guardados.

Segundo recibo: a instância ativa

A documentação de service accounts do Kubernetes distingue TokenRequest, tokens vinculados e TokenReview. O kubelet pode solicitar tokens conforme o Pod e entregá-los aos contêineres; os claims podem nomear namespace, service account, Pod e node.

Esses claims são uma fotografia. O Pod pode terminar, outra réplica pode manter a mesma conta e a política pode mudar. Verificação offline confirma assinatura e conteúdo, não a existência atual do objeto. O rascunho ressalta que a invalidação por remoção só é detectada quando TokenReview é usado. É preciso registrar instância, estado de ciclo de vida, epoch de scheduling e política e hora da consulta.

Terceiro recibo: emissão e entrega

Emitir os bytes corretos não garante que o consumidor certo os carregou. Em arquivos, o rascunho recomenda renovação antes da invalidação, troca atômica e flush. APIs locais por Unix socket, loopback ou endereço link-local entregam e renovam sob demanda. Variáveis de ambiente são estáticas e vazam facilmente em diagnóstico; não devem ser usadas quando há alternativa.

Um rename atômico evita um arquivo pela metade, mas não faz todo processo reabrir o caminho nem apaga cópias na memória. Uma resposta de API não prova ausência de SSRF ou de interceptação por componente privilegiado. O recibo precisa ligar canal, instância, hash e confirmação de consumo.

Quarto recibo: posse da chave

Bearer tokens roubados podem ser reutilizados até expirar. Por isso o texto recomenda proof of possession. X.509 demonstra controle da chave durante o handshake; JWTs podem ser key-bound. O RFC 8705 define access tokens OAuth ligados a certificado mTLS.

A prova é estreita. Ela não demonstra que a chave nunca foi copiada, que só um processo pode acioná-la ou que ele ainda é a carga observada no bootstrap. Sidecar, agente de node ou interface HSM podem usar a chave sem exportá-la. Custódia exclusiva exige evidência separada.

Quinto recibo: audiência e autorização

O rascunho recomenda uma credencial por recurso ou provedor de identidade e uma audiência por JWT. Um token voltado à API do Kubernetes não deve ser reaproveitado fora dela. A separação reduz o raio de dano.

Mas aud indica quem pode aceitar o token, não qual operação está permitida. O RFC 7521 fornece o framework de assertions OAuth e o RFC 7523 o perfil JWT bearer. Uma assertion aceita ainda precisa encontrar política atual que autorize verbo, objeto e parâmetros.

O Artigo anterior da BTW sobre OAuth agêntico tratou da autoridade sobre argumentos finais gerados pelo modelo. Este trata da cadeia distinta de identidade: bootstrap, vínculo runtime, entrega, posse e expiração.

Sexto recibo: concluir a rotação

Vida curta reduz a janela de ataque, não revoga de imediato. Emitir o novo valor antes de invalidar o antigo cria sobreposição deliberada. Aplicações, pools, proxies e filas podem reter o token anterior. Backups, snapshots e imagens também preservam cópias; memória reduz essa exposição sem provar limpeza universal.

O emissor deveria invalidar cada instância parada ou removida e oferecer consulta de estado, mas o mecanismo fica fora do escopo do documento. “Rotacionado” exige nova emissão, adoção pelos consumidores, rejeição ou expiração do valor antigo e drenagem dos caches e instâncias conhecidos.

Sétimo e oitavo recibos: execução e resultado

Os textos WIMSE de arquitetura, credenciais, assinaturas HTTP e mTLS reforçam partes da autenticação. Nenhum comprova que a aplicação produziu efeito.

O recurso pode validar emissor, tempo, audiência, tipo, chave e claims e ainda negar a ação. Pode aceitar e falhar antes do commit. Um proxy compartilhado pode autenticar por várias cargas. O serviço executor deve emitir o recibo de requisição canônica, autorização, transação e commit; o observador do estado final deve emitir outro recibo para o resultado.

A diferença de Heng Lu entre camada real e simbólica torna o erro visível: token e resposta de sucesso significam algo, mas realidade é o estado executado e observado. A especificação mínima com validação local e a primazia do código em funcionamento pedem que cada prova permaneça perto do sistema capaz de verificá-la.

A arquitetura confiável responde oito perguntas distintas: o que a plataforma observou; qual instância foi vinculada; o que foi emitido e entregue; qual chave foi provada; qual audiência e operação foram autorizadas; onde o token antigo deixou de funcionar; se o pedido foi executado; e se o resultado apareceu.