Autenticação de Registry Mirror com Kubernetes Secrets

O recurso não é só uma mudança de local de armazenamento de credenciais: ele reprojeta o fluxo de autenticação em tempo de pull. Antes, credenciais para mirrors eram injetadas no nível do nó via arquivos estáticos ou configurações globais do CRI-O, o que violava o princípio de isolamento de tenants e exigia reinicialização do runtime para atualizações. Agora, o kubelet chama um plugin externo que usa o token da service account do pod para identificar o namespace, busca secrets específicos nesse escopo, gera um arquivo de auth efêmero com TTL implícito (não persistente) e limpa tudo após o pull. Isso elimina a necessidade de credenciais compartilhadas entre namespaces e remove o risco de vazamento acidental por meio de mounts ou logs.

A funcionalidade depende de três pilares alinhados: Kubernetes 1.33+ com o feature gate KubeletServiceAccountTokenForCredentialProviders ativado, CRI-O 1.34+, e a API de Credential Provider estável desde o Kubernetes 1.26. O arquivo gerado, como /etc/crio/auth/<namespace>-<sha256>.json, nunca é acessível fora do ciclo do pull, nem exposto ao usuário ou ao pod. É um mecanismo nativo de infraestrutura como código, não uma gambiarra com initContainers ou sidecars personalizados.

Em ambientes multi-tenant, como provedores de Kubernetes-as-a-Service ou clusters OpenShift usados por múltiplos times, autenticar mirrors com secrets de namespace reduz drasticamente a superfície de ataque. Um tenant comprometido não consegue extrair credenciais de outro, mesmo que tenha acesso ao nó. Também simplifica operações: equipes de plataforma podem rotacionar credenciais de mirror por tenant sem derrubar workloads ou reiniciar o CRI-O. A integração com OpenShift 4.21 (RPM pré-instalado) e a previsão de suporte declarativo na versão 4.22 indicam que esse modelo está se tornando padrão de fato para entrega segura de imagens em nuvem privada e híbrida.