No ecossistema de produção Kubernetes, a recuperação de imagens de container privadas ocorre milhares de vezes ao dia. Enquanto provedores cloud como AWS, Google e Azure oferecem mecanismos nativos de credential providers, um desafio crítico surge quando operamos em ambientes com registry mirrors ou pull-through caches. É o cenário clássico de empresas que buscam reduzir custos de egress, otimizar o latency de deployment ou isolar o tráfego em redes air-gapped.
Historicamente, configurar o acesso a esses espelhos envolvia intervenção no nível do nó (via /etc/containers/registries.conf). Isso cria uma dependência de configuração global que fere o princípio do least privilege e compromete o isolamento entre tenants no cluster. O projeto CRI-O introduziu um credential provider que resolve esse impasse, permitindo que a autenticação use objetos nativos do Kubernetes: Secrets.
O Problema: Credenciais em Nível de Nó
A arquitetura atual do kubelet ignora a configuração de espelhos, deixando-a sob responsabilidade do runtime (CRI-O/Containerd). Isso gera três problemas graves:
- Quebra de Isolamento: Se as credenciais vivem no nó, todos os namespaces compartilham o mesmo segredo ao buscar imagens. Um pod em 'Namespace A' pode ter visibilidade indevida sobre o acesso ao 'Namespace B'.
- Complexidade Operacional: A gestão centralizada torna-se um gargalo. Cada nova necessidade de acesso requer intervenção de administradores em vez de permitir autonomia para as equipes de desenvolvimento.
- Compliance: Em ambientes regulados, o compartilhamento indiscriminado de segredos viola políticas de segurança, dificultando auditorias de acesso.
A Solução: Kubelet Credential Provider Plugin
A partir do Kubernetes 1.26 (e com refinamentos no 1.33), o kubelet image credential provider plugin API permite que executáveis externos processem autenticações de forma dinâmica. O componente-chave aqui é o feature gate KubeletServiceAccountTokenForCredentialProviders, que viabiliza a passagem do service account token do pod para o plugin.
O fluxo é elegante: o provider intercepta o pedido de pull, valida o token do ServiceAccount, descobre o namespace por trás da requisição e busca as Secrets correspondentes. Esse processo mantém o controle de acesso granular enquanto preserva o ganho de performance dos mirrors.
Workflow Técnico e Componentes
O processo pode ser resumido em:
- O Kubelet invoca o provider com o nome da imagem e o service account token.
- O provider extrai o namespace, consulta a API do Kubernetes para localizar Secrets (tipo
kubernetes.io/dockerconfigjson) naquele contexto. - O provider gera um arquivo de auth temporário que o CRI-O utiliza apenas para aquele pull específico, garantindo que o segredo não fique persistente ou exposto globalmente.
Para times de engenharia no Brasil que operam clusters multi-tenant, entender essa arquitetura é fundamental. A implementação exige um ajuste fino no RBAC: é obrigatório garantir que o ClusterRole de cada nó tenha permissão de request-serviceaccounts-token-audience e que o service account do pod tenha permissão de get e list em secrets em seu próprio namespace.
Considerações Finais
A adoção de namespace-scoped authentication para registry mirrors não é apenas uma melhoria de usabilidade; é um pilar de segurança em arquiteturas Cloud Native maduras. Ao eliminar a necessidade de credenciais globais nos nós, reduzimos drasticamente a superfície de ataque em caso de comprometimento de pods.
Fique atento: para empresas que usam distribuições como OKD ou OpenShift, essa integração tende a se tornar ainda mais declarativa conforme as versões avançam. A estabilidade de um cluster depende da capacidade de reduzir o overhead de configuração, mantendo a autonomia necessária para o crescimento acelerado dos times de produto.
Artigo originalmente publicado por Sascha Grunert, Red Hat em Cloud Native Computing Foundation.
