← back

📷 "Free circuit board macro image" is marked with CC0 1.0. To view the terms, visit https://creativecommons.org/publicdomain/zero/1.0/.

Argo CD 3.5: Internal mTLS, Source Integrity, and the New ApplicationSet UI

29 September 2026 · 5 min · Martin Jochum #ArgoCD#GitOps#Kubernetes#DevOps#Security#mTLS#Supply Chain Security

Argo CD 3.5 is here: Internal mTLS, Source Integrity, and the new ApplicationSet UI

Security requirements for Kubernetes deployment pipelines are rising rapidly. Argo CD, the leading GitOps tool with nearly 60 percent adoption in Kubernetes clusters, has released version 3.5 (GA in August 2026), which closes two long-standing security gaps and significantly improves usability. In September, the release candidate for v3.6 followed – development is accelerating. This article provides an overview of the most important innovations and shows why the upgrade is particularly worthwhile for security-conscious teams.

Internal mTLS: The biggest security gain

Probably the most significant innovation in Argo CD 3.5 is mutual TLS authentication (mTLS) between internal components. Until now, communication between the repo-server and other services such as the API server, Application Controller, and ApplicationSet Controller was unencrypted and unauthenticated. An attacker with network access to the repo-server could connect without authentication.

A security vulnerability published in July 2026 exploited exactly this gap: an unauthenticated attacker could misuse a Kustomize option via the repo-server to execute arbitrary commands, read the Redis password from an environment variable, and manipulate cached deployment data – without a CVE and without credentials. The bug had been reported to the maintainers 18 months before disclosure.

With mTLS in v3.5, the repo-server now requires a valid client certificate from every connected component. If you don’t provide your own certificates, you automatically receive self-signed certificates generated in memory by the repo-server – full filesystem access is not required. The feature is additive: existing clusters without their own certificates automatically receive the mTLS fallback solution, without requiring reconfiguration.

Important note: mTLS does not replace NetworkPolicies, but supplements them as a second defense layer. If you activate the NetworkPolicies included in the Helm chart, you already protect the repo-server at the network level. mTLS additionally covers the case where network isolation is incomplete or bypassed by lateral movement from another pod in the same namespace.

Source Integrity: Signed Git commits as a deployment gate

The second major security feature is native Git commit signature verification, called Source Integrity. Previously, it was sufficient that a commit existed on the configured branch – Argo CD deployed it, regardless of who pushed it or whether it was subsequently tampered with.

With Source Integrity, the operator can specify that only signed commits may be synchronized. Specifically: in the Application spec, set sourceIntegrity.required: true, or via the CLI argocd app set --source-integrity-required. A commit without a valid signature will then be excluded from synchronization.

This addresses a real scenario: a leaked GitHub personal access token, a compromised developer laptop, or a force push during an incident – in all these cases, the commit on the branch looks “legitimate”. The only question that Source Integrity answers and that stands before a deployment decision is: Was this specific commit signed by a key authorized to approve production changes?

The older GPG verification is now deprecated and will be removed in the next major version.

ApplicationSet UI: Visibility for GitOps scaling

ApplicationSets have long been a central feature for multi-cluster deployments. They allow templating the same application across multiple clusters or environments. Until now, however, they lacked native representation in the web interface – administrators had to read YAML or use kubectl to see which concrete applications an ApplicationSet template would generate.

The new ApplicationSet UI, developed by engineers at Intuit, Red Hat, GoTo, and Octopus Deploy, now offers:

  • A list view of all ApplicationSets
  • Filter and detail views
  • A Preview Apps tab that shows which applications an ApplicationSet template will generate before deployment

The preview tab in particular is a practical gain: it makes ApplicationSets more accessible for developer teams and reduces the risk of misconfiguration when scaling.

Other innovations at a glance

In addition to the three main features, Argo CD 3.5 brings a range of other improvements:

  • Impersonation (Beta): Argo CD can assume a specific user identity for server-side tasks – relevant for audit trails in multi-tenant clusters.
  • Source Hydrator (Beta): The separation of dry (unhydrated) and hydrated manifests reaches beta status. Different repositories for source templates and rendered manifests are supported.
  • Helm 4 support: Alongside backward compatibility with Helm 3.
  • Any-Namespace ApplicationSets: ApplicationSets can be deployed in any namespace, not just the Argo CD namespace.
  • Concurrency controls: Limiting the number of simultaneously processed applications – protects against cluster overload.
  • Azure AD improvements: Group claims overflow is resolved via the Microsoft Graph API, and Azure DevOps receives service principal authentication.

Conclusion

Argo CD 3.5 is more than a routine release. With internal mTLS and Source Integrity, the project closes two security gaps that were no longer acceptable given this level of adoption. The new ApplicationSet UI makes multi-cluster GitOps accessible to broader teams. As of September 2026, the release candidate for v3.6 is already available – the development speed shows that Argo CD is not standing still despite its market dominance.

For teams running Argo CD in production, upgrading to v3.5 is strongly recommended, especially from a security perspective. The mTLS feature can be used without manual certificate management thanks to automatic self-signed certificates, and Source Integrity can be enabled per application – both with low migration effort.

Sources

🌐 Machine-translated from the German original, editorially reviewed. 🤖 Written with AI assistance.

Sponsored
Deine Anzeige hier — erreiche Tech-affine Leser. Kontakt: info@saaro.net→