Argo CD 3.5 eleva nível de segurança em GitOps com mTLS e validação de commits

O ApplicationSet é um recurso do ecossistema Argo CD que automatiza a criação de múltiplas instâncias de aplicações a partir de templates parametrizados, por exemplo, implantar a mesma aplicação em dezenas de namespaces ou clusters com variações controladas. Ele funciona como uma camada de geração declarativa: você define um template (como um Application) e um conjunto de parâmetros (via Git, Cluster, ou HTTP), e o controller do ApplicationSet renderiza os Application objects reais no cluster. Até o v3.4, não havia suporte nativo na UI para visualizar, filtrar ou prever essas instâncias, operadores dependiam de kubectl get applicationset ou leitura de YAML. A versão 3.5 fecha essa lacuna com uma interface dedicada, incluindo Preview Apps, que mostra exatamente quais Applications serão criados antes do sync, evitando surpresas em produção.

O mTLS interno resolve uma dívida técnica antiga: comunicação entre repo-server, API server e controllers era feita via gRPC sem criptografia, mesmo em clusters com mTLS externo ativo. Agora, o repo-server emite certificados autoassinados em memória (sem depender de arquivos no disco) e exige certificados válidos dos clientes, isso protege contra escuta interna e ataques de 'man-in-the-middle' entre componentes, especialmente relevante em ambientes multi-tenant ou com políticas de zero trust. Já a Source Integrity não é apenas verificação de assinatura GPG: ela impõe uma política explícita no Application spec (sourceIntegrity.required: true) ou via CLI, bloqueando syncs se o commit mais recente não tiver assinatura válida, algo que nem Flux nem Fleet oferecem nativamente como mecanismo integrado ao ciclo de sincronização.

Na cobertura CEVIU de 26/06, destacamos o lançamento do RC com ApplicationSet UI e beta de impersonation e Source Hydrator. Agora, com o release oficial em 03/07, o mTLS interno passa de RFC para funcionalidade estável, e não é só ativação: o comportamento padrão agora exige certificados, com fallback seguro para self-signed em memória. Também houve refinamento prático na Source Integrity: o flag --source-integrity-required foi expandido para suportar exclusões por branch ou tag via sourceIntegrity.exclude, algo não mencionado no RC mas confirmado na documentação final. Além disso, o ApplicationSet UI ganhou a capacidade de comparar dois previews lado a lado, útil para validar mudanças em templates antes de merge, feature ausente no anúncio inicial.

Para equipes que operam GitOps em escala, essas atualizações reduzem três riscos críticos: 1) exposição de tráfego interno entre componentes do Argo CD, que poderia ser explorada em ambientes com múltiplos tenants; 2) deploy acidental de manifests de commits adulterados ou não assinados, um vetor real de supply chain attack já observado em incidentes com repositórios comprometidos; 3) falhas de configuração em ApplicationSets que só aparecem após o sync, gerando downtime ou inconsistência entre ambientes. O fato de o Source Hydrator ter atingido beta com suporte a drySource e syncSource em repositórios distintos também permite separar responsabilidades: time de plataforma mantém templates, time de produto controla manifestos renderizados, sem depender de webhooks ou pipelines externos.