Argo CD 3.5: Mehr Sicherheit und eine neue UI für ApplicationSets

📷 "Computer Board" by Lenharth Systems is marked with CC0 1.0. To view the terms, visit https://creativecommons.org/publicdomain/zero/1.0/.

Am 4. August 2026 wurde Argo CD 3.5 veröffentlicht – die bisher ausgereifteste Version des führenden GitOps-Tools für Kubernetes. Mit Fokus auf Lieferkettensicherheit, einer nativen UI für ApplicationSets und Helm-4-Support markiert das Release einen Meilenstein in der Entwicklung des CNCF-Projekts. Zeit für einen Blick auf die wichtigsten Neuerungen der 3.x-Reihe und darauf, was sie für DevOps-Teams bedeuten.

Der Weg zur Version 3.5

Die 3.x-Ära von Argo CD begann Anfang 2025 mit einer grundlegenden Überarbeitung der Architektur. Seitdem hat das Projekt eine bemerkenswerte Release-Cadence vorgelegt: Version 3.1 (August 2025) brachte native OCI-Registry-Unterstützung und CLI-Plugins, 3.2 (November 2025) optimierte Webhook-Handler und verbesserte das ApplicationSet Progressive Sync. Version 3.3 führte erweiterte Health-Checks für Drittanbieter-Operatoren wie CloudNativePG und KEDA ein, während 3.4 die längst überfällige Microsoft-Teams-Integration über Workflows statt der deprecated Office-365-Connectors nachreichte.

Mit Version 3.5, die nach zwei Release Candidates am 4. August 2026 erschienen ist, setzt Argo CD nun neue Maßstäbe in drei Bereichen: Sicherheit, Benutzeroberfläche und Plattformflexibilität.

Interne mTLS-Verschlüsselung: Ein Gewinn für die Sicherheitsarchitektur

Die wohl wichtigste Neuerung in Argo CD 3.5 betrifft die interne Kommunikation. Bisher war der Datenverkehr zwischen dem Repo-Server und anderen Komponenten wie dem API-Server und den Controllern unverschlüsselt – eine Lücke, die in sicherheitsbewussten Umgebungen zunehmend kritisch gesehen wurde.

Argo CD 3.5 führt daher mutual TLS (mTLS) für alle internen Komponenten ein. Der Repo-Server akzeptiert nun nur noch Verbindungen mit gültigen Client-Zertifikaten. Für Umgebungen ohne eigene PKI-Infrastruktur generiert der Server selbstsignierte Zertifikate im Arbeitsspeicher – eine pragmatische Lösung, die auf das Dateisystem verzichtet und gleichzeitig Health-Checks ermöglicht. Damit schließt Argo CD eine Sicherheitslücke, die bisher durch Netzwerk-Firewalls oder Service-Meshes extern abgesichert werden musste.

Source Integrity: Vertrauen in die Git-Quelle

Ein weiteres Sicherheits-Highlight ist die Git-Commit-Signatur-Prüfung (Source Integrity). Administratoren können nun erzwingen, dass nur signierte Commits aus dem Git-Repository synchronisiert werden dürfen. Die Konfiguration erfolgt entweder deklarativ im Application-Manifest über sourceIntegrity.required: true oder per CLI mit argocd app set --source-integrity-required. Das verhindert, dass ein kompromittiertes Repository ungeprüfte oder manipulierte Manifests ausrollt – ein entscheidender Baustein für Lieferkettensicherheit im Sinne von SLSA-Level-2 und höher.

Damit holt Argo CD zu Flux auf, das native GPG-Signatur-Prüfung bereits länger im GitRepository-API unterstützt. In Kombination mit der neuen mTLS-Absicherung internen Traffics adressiert das Release zwei der drängendsten Sicherheitsanforderungen in Enterprise-Umgebungen.

ApplicationSets endlich im UI sichtbar

ApplicationSets sind in großen GitOps-Deployments mit Dutzenden oder Hunderten von Microservices unverzichtbar: Sie generieren aus einer Vorlage automatisch mehrere Applications für verschiedene Umgebungen oder Cluster. Bisher blieb ihre Verwaltung jedoch YAML- und kubectl-Liebhabern vorbehalten – eine native UI-Oberfläche fehlte.

Argo CD 3.5 ändert das: Die neue ApplicationSet-UI (entwickelt von Ingenieuren bei Intuit, Red Hat, GoTo und Octopus Deploy) bietet Listen-, Filter- und Detailansichten. Besonders praktisch ist der Preview-Apps-Tab, der vor der eigentlichen Synchronisation anzeigt, welche konkreten Applications aus einer ApplicationSet-Vorlage generiert werden. Das reduziert Fehler und beschleunigt die Arbeit von Plattform-Teams erheblich.

Plattform-Fortschritte: Helm 4, Namespace-freie ApplicationSets und mehr

Neben den großen Drei bringt Argo CD 3.5 eine Reihe weiterer Verbesserungen:

Helm 4-Unterstützung bei gleichzeitiger Abwärtskompatibilität zu Helm 3, sodass Teams schrittweise migrieren können.
ApplicationSets in beliebigen Namespaces – ein lang geforderter Feature-Wunsch, der die mandantenfähige Bereitstellung von GitOps-Workflows pro Team-Namespace ermöglicht.
ApplicationSet Concurrency Controls, die die Anzahl gleichzeitig verarbeiteter Applications begrenzen und damit Cluster- sowie API-Überlastung vermeiden.
Impersonation (von Alpha zu Beta) erlaubt es Argo CD, für serverseitige Aufgaben eine spezifische Benutzeridentität anzunehmen – ein Gewinn für Audit-Logs in Multi-Tenant-Clustern.
Source Hydrator (ebenfalls Beta) trennt trockene (unhydrierte) Manifests von ihren gerenderten Ausgaben und ermöglicht Multi-Repository-GitOps-Patterns mit getrennten Zugriffskontrollen.
Azure AD und Azure DevOps erhalten verbesserte Integrationen: Group-Claims werden über die Microsoft-Graph-API aufgelöst, und Service-Principal-Authentifizierung ersetzt die bisher nötigen PATs.

Fazit

Argo CD 3.5 ist kein revolutionäres, aber ein hochwertiges Evolutions-Release. Die Kombination aus interner mTLS-Verschlüsselung, Git-Commit-Signatur-Prüfung und der lang erwarteten ApplicationSet-UI macht es zum bisher ausgereiftesten GitOps-Werkzeug für Kubernetes. Teams, die noch auf Version 2.14 oder älter laufen, sollten den Upgrade-Pfad über die 3.x-Reihe jetzt ernsthaft angehen – die drei letzten Minor-Versionen sind 3.5, 3.4 und 3.3; ältere Releases erhalten keine Sicherheitsupdates mehr. Argo CD bleibt damit der De-facto-Standard für deklaratives Continuous Delivery auf Kubernetes – sicherer, sichtbarer und skalierbarer als je zuvor.