A comunidade de DevOps recebeu uma atualização significativa com o lançamento do candidato a release Argo CD 3.5. Esta versão ataca um dos pontos críticos em ambientes corporativos de grande escala: a segurança interna do tráfego e a integridade da cadeia de suprimentos de software (supply chain security).
Com a introdução de mTLS interno e validação de commits, o projeto reforça sua posição como a principal ferramenta de GitOps no ecossistema Kubernetes.
O grande diferencial desta atualização é a implementação de mTLS (mutual TLS) para comunicação entre componentes internos, como o servidor de repositórios (repo-server) e os demais serviços.
Até então, o tráfego interno não contava com essa camada extra de proteção, criando vulnerabilidades em clusters onde a segurança de rede interna não estava totalmente segmentada. Agora, o repo-server exige certificados de cliente, podendo gerar certificados autoassinados em memória caso o ambiente não possua uma infraestrutura de PKI complexa.
Segurança da cadeia de suprimentos e integridade
A integridade de repositórios Git tornou-se uma preocupação central para arquitetos de segurança. O Argo CD 3.5 resolve o risco de deploys baseados em manifestos alterados ou maliciosos através do recurso de Source Integrity.
Com a flag --source-integrity-required ou via especificação no Application, operadores podem garantir que apenas commits com assinaturas verificadas sejam sincronizados.
Em paralelo, o recurso Source Hydrator atingiu o status beta. Ele permite a separação entre manifestos não hidratados e o resultado final, possibilitando padrões GitOps multi-repositório. Essa separação é fundamental para times que precisam aplicar controles de acesso distintos entre o template da infraestrutura e o manifesto renderizado final.
Gestão avançada com ApplicationSet na UI
Uma das maiores reclamações de usuários, o gerenciamento de ApplicationSets, recebeu atenção especial com suporte nativo na interface gráfica. Desenvolvido por uma colaboração entre empresas como Intuit e Red Hat, o novo painel permite:
Visualização de listas, filtros e detalhes de ApplicationSets.
Aba de Preview Apps, que exibe exatamente o que será criado antes da efetiva aplicação no cluster.
Suporte para deploy de ApplicationSets em qualquer namespace, não restringindo mais o uso ao namespace do Argo CD.
Controle de concorrência para evitar sobrecarga na API do Kubernetes ou no provider Git.
Comparações no mercado e ecossistema
Ao comparar com ferramentas concorrentes, como o Flux, nota-se abordagens arquiteturais distintas. Enquanto o Flux utiliza objetos da API do Kubernetes para comunicação (o que, por design, ignora a necessidade de mTLS interno em gRPC), o Argo CD opta por reforçar a segurança em seu modelo de comunicação direta.
A vantagem do Argo CD 3.5 agora reside na visibilidade e controle que a nova UI proporciona para operações complexas, um gap que ferramentas como o Flux ainda buscam preencher com operadores externos.
Perguntas Frequentes sobre Argo CD 3.5
O que é o novo mTLS interno no Argo CD 3.5?
É uma camada de segurança que criptografa e autentica a comunicação entre os componentes internos do Argo CD, como repo-server e API server, utilizando certificados mútuos.
Como ativar a verificação de integridade de commits?
Pode ser ativado definindo sourceIntegrity.required: true na especificação da Application ou utilizando a flag --source-integrity-required via CLI.
O suporte a Helm 4 já está disponível?
Sim, o Argo CD 3.5 adiciona suporte ao Helm 4, mantendo total compatibilidade retroativa com fluxos que utilizam Helm 3.
O recurso de Impersonation já pode ser usado em produção?
O recurso chegou ao status beta nesta versão, permitindo que o Argo CD assuma identidades específicas para tarefas de sincronização e auditoria, sendo ideal para ambientes multi-tenant.
O que mudou para usuários do Azure AD?
Usuários que enfrentavam limites de tamanho em tokens OIDC devido a overflow de grupos podem agora realizar a resolução de grupos via Microsoft Graph API.
