Argo CD 3.5: Interne mTLS, Source Integrity und die neue ApplicationSet-UI

📷 "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 ist da: Interne mTLS, Source Integrity und die neue ApplicationSet-UI

Die Sicherheitsanforderungen an Kubernetes-Deployment-Pipelines steigen rasant. Argo CD, das führende GitOps-Tool mit fast 60 Prozent Adoption in Kubernetes-Clustern, hat mit Version 3.5 (GA im August 2026) einen Release vorgelegt, der zwei langjährige Sicherheitslücken schließt und die Bedienung deutlich verbessert. Im September folgte bereits der Release Candidate für v3.6 – die Entwicklung beschleunigt sich. Dieser Artikel gibt einen Überblick über die wichtigsten Neuerungen und zeigt, warum der Upgrade besonders für sicherheitsbewusste Teams lohnenswert ist.

Interne mTLS: Der größte Sicherheitsgewinn

Die wohl bedeutendste Neuerung in Argo CD 3.5 ist die gegenseitige TLS-Authentifizierung (mTLS) zwischen den internen Komponenten. Bislang war die Kommunikation zwischen dem repo-server und anderen Diensten wie dem API-Server, Application Controller und ApplicationSet Controller unverschlüsselt und unauthentisiert. Ein Angreifer mit Netzwerkzugriff auf den repo-server konnte sich ohne Authentifizierung verbinden.

Genau diese Lücke machte sich eine im Juli 2026 veröffentlichte Sicherheitslücke zunutze: Ein unauthentisierter Angreifer konnte über den repo-server eine Kustomize-Option missbrauchen, um beliebige Befehle auszuführen, das Redis-Passwort aus einer Umgebungsvariable auszulesen und gecachte Deployment-Daten zu manipulieren – ohne CVE und ohne Credentials. Der Fehler war den Maintainern bereits 18 Monate vor der Offenlegung gemeldet worden.

Mit mTLS in v3.5 verlangt der repo-server nun ein gültiges Client-Zertifikat von jeder verbundenen Komponente. Wer keine eigenen Zertifikate bereitstellt, erhält automatisch vom repo-server generierte Self-Signed-Certs aus dem Arbeitsspeicher – ein vollständiger Dateisystemzugriff ist nicht nötig. Die Funktion ist additiv: Bestehende Cluster ohne eigene Zertifikate erhalten automatisch die mTLS-Fallback-Lösung, ohne dass eine Neukonfiguration erforderlich ist.

Wichtig ist: mTLS ersetzt keine NetworkPolicies, sondern ergänzt sie als zweite Verteidigungsschicht. Wer die in der Helm-Chart mitgelieferten NetworkPolicies aktiviert, schützt den repo-server bereits auf Netzwerkebene. mTLS sichert zusätzlich den Fall ab, dass die Netzwerkisolation unvollständig oder durch laterale Bewegung von einem anderen Pod im selben Namespace umgangen wird.

Source Integrity: Signierte Git-Commits als Deployment-Gate

Das zweite große Sicherheitsfeature ist die native Git-Commit-Signaturprüfung, genannt Source Integrity. Bislang reichte es aus, dass ein Commit auf dem konfigurierten Branch existierte – Argo CD deployte ihn, unabhängig davon, wer ihn gepusht hatte oder ob er nachträglich manipuliert wurde.

Mit Source Integrity kann der Operator festlegen, dass nur signierte Commits synchronisiert werden dürfen. Konkret: Im Application-Spec wird sourceIntegrity.required: true gesetzt, oder per CLI argocd app set --source-integrity-required. Ein Commit ohne gültige Signatur wird dann von der Synchronisation ausgeschlossen.

Das schließt ein reales Szenario ab: Ein geleakter GitHub-Personal-Access-Token, ein kompromittierter Entwickler-Laptop oder ein Force-Push während eines Incidents – in all diesen Fällen sieht der Commit auf dem Branch „legitim" aus. Die einzige Frage, die Source Integrity beantwortet und die vor einer Deployment-Entscheidung steht, ist: Wurde dieser spezifische Commit von einem Schlüssel signiert, der zur Autorisierung von Produktionsänderungen berechtigt ist?

Die ältere GPG-Verifikation ist damit deprecated und wird in der nächsten Hauptversion entfernt.

ApplicationSet UI: Sichtbarkeit für GitOps-Skalierung

ApplicationSets sind seit längerem ein zentrales Feature für Multi-Cluster-Deployments. Sie erlauben es, dieselbe Anwendung über mehrere Cluster oder Umgebungen zu templaten. Bislang fehlte ihnen jedoch eine native Darstellung in der Weboberfläche – Administratoren mussten YAML lesen oder kubectl verwenden, um zu sehen, welche konkreten Anwendungen ein ApplicationSet-Template erzeugen würde.

Die neue ApplicationSet-UI, entwickelt von Ingenieuren bei Intuit, Red Hat, GoTo und Octopus Deploy, bietet jetzt:

Eine Listenansicht aller ApplicationSets
Filter- und Detailansichten
Einen Preview-Apps-Tab, der vor dem Deployment zeigt, welche Anwendungen ein ApplicationSet-Template erzeugen wird

Gerade der Preview-Tab ist ein praktischer Gewinn: Er macht ApplicationSets für Entwicklerteams zugänglicher und reduziert das Risiko von Fehlkonfigurationen bei der Skalierung.

Weitere Neuerungen auf einen Blick

Neben den drei Hauptfeatures bringt Argo CD 3.5 eine Reihe weiterer Verbesserungen:

Impersonation (Beta): Argo CD kann eine bestimmte Benutzeridentität für serverseitige Aufgaben annehmen – relevant für Audit-Trails in Multi-Tenant-Clustern.
Source Hydrator (Beta): Die Trennung von trockenen (unhydrierten) und hydrierten Manifests erreicht Beta-Status. Unterschiedliche Repositories für Quellvorlagen und gerenderte Manifests werden unterstützt.
Helm 4-Unterstützung: Neben der Abwärtskompatibilität zu Helm 3.
Any-Namespace ApplicationSets: ApplicationSets können in beliebigen Namespaces deployed werden, nicht nur im Argo-CD-Namespace.
Concurrency-Controls: Begrenzung der gleichzeitig verarbeiteten Anwendungen – schützt vor Überlastung des Clusters.
Azure AD-Verbesserungen: Group-Claims-Overflow wird über die Microsoft Graph API gelöst, Azure DevOps erhält Service-Principal-Authentifizierung.

Fazit

Argo CD 3.5 ist mehr als ein Routine-Release. Mit internem mTLS und Source Integrity schließt das Projekt zwei Sicherheitslücken, die bei diesem Verbreitungsgrad lange nicht akzeptabel waren. Die neue ApplicationSet-UI macht Multi-Cluster-GitOps für breitere Teams zugänglich. Im September 2026 liegt bereits der Release Candidate für v3.6 vor – die Entwicklungsgeschwindigkeit zeigt, dass Argo CD trotz seiner Marktdominanz nicht stehenbleibt.

Für Teams, die Argo CD produktiv betreiben, ist der Upgrade auf v3.5 besonders aus Sicherheitsperspektive dringend zu empfehlen. Die mTLS-Funktion ist dank automatischer Self-Signed-Certs ohne manuelle Zertifikatsverwaltung einsetzbar, und die Source Integrity lässt sich pro Application zuschalten – beides mit geringem Migrationsaufwand.