Argo CD 3.5 Release Candidate Enhances Supply Chain Security and GitOps Features

The Argo CD project has announced the release candidate for version 3.5, bringing a suite of enhancements focused on strengthening supply chain security and improving the overall GitOps experience. A major highlight is the new enforcement of mutual TLS (mTLS) for internal communications between Argo CD components, such as the repo-server and API server. Previously, internal traffic within Argo CD was unencrypted, posing a potential security risk in large-scale deployments. This update addresses that vulnerability by ensuring all internal communication is encrypted, aligning with best practices for secure infrastructure. Another critical security improvement is the introduction of Git commit signature verification. This feature allows Argo CD to verify the authenticity and integrity of Git commits, preventing the silent deployment of unsigned or tampered manifests from a compromised Git repository. This is a significant step forward in securing the software supply chain for Kubernetes deployments managed by Argo CD. Operational improvements are also a core part of this release. The v3.5 release candidate now offers native management of ApplicationSets directly within the Argo CD user interface. This long-requested feature provides list, filter, and detail views for ApplicationSets, along with a 'Preview Apps' tab, enabling operators to visualize the applications an ApplicationSet template will create before deployment. This streamlines the management of numerous similar applications. Furthermore, two key features have progressed from alpha to beta status: impersonation and Source Hydrator. Impersonation allows Argo CD to assume a specific user identity for server-side tasks like log streaming and resource deletion, which is vital for maintaining comprehensive audit trails in multi-tenant Kubernetes clusters. The Source Hydrator, now in beta, separates dry (unhydrated) manifests from their hydrated output, facilitating multi-repository GitOps patterns where source templates and rendered manifests can reside in different repositories with distinct access controls. Other notable additions include Helm 4 support, alongside continued backward compatibility with Helm 3, and the ability to deploy ApplicationSets in any namespace, not just the Argo CD namespace. These changes contribute to greater flexibility and stability for teams adopting GitOps at scale.