Argo CD 3.5: de Helm 3→4-migratie en andere breaking changes

Argo CD 3.5 (uitgekomen 4 augustus 2026) is geen kleine patch — de meest in het oog springende wijziging is de overstap van Helm 3 naar Helm 4 als onderliggende renderer. Dat klinkt ingrijpender dan het in de praktijk is, maar er zitten wel een paar concrete breaking changes bij die je vóór het upgraden wilt kennen.

Het belangrijkste geruststellende feit eerst

Argo CD roept nooit helm install of helm upgrade aan — het gebruikt helm template om manifesten te renderen, en past die vervolgens toe met zijn eigen sync-engine. Dat betekent dat de grote, spraakmakende Helm 4-wijziging voor directe CLI-gebruikers — Server-Side Apply (SSA) als nieuwe standaard — Argo CD zelf niet raakt op dezelfde manier. Argo CD heeft al zijn eigen SSA-ondersteuning via de ServerSideApply: true-syncoptie op het Application-object, volledig los van wat Helm 4 zelf als standaard hanteert.

Examentip: Als je elders leest over grote Helm 4-breaking-changes (SSA-gedrag, kstatus/RBAC voor --wait, enz.), controleer dan of dat artikel over directe Helm-CLI-gebruik gaat of specifiek over Argo CD — die twee werelden overlappen minder dan je zou verwachten.

De breaking changes die Argo CD 3.5 wél specifiek raken

1. GnuPG-signatuurverificatie is deprecated

Werkte je met argocd proj add-signature-key / remove-signature-key, of met .spec.signatureKeys in een AppProject? Die blijven in 3.5 nog functioneren (met een waarschuwing), maar de aanbevolen, nieuwe route is sourceIntegrity in de AppProject-YAML.

apiVersion: argoproj.io/v1alpha1nkind: AppProjectnmetadata:n  name: mijn-projectnspec:n  signatureKeys:n    - keyID: ABCD1234EFGH5678

apiVersion: argoproj.io/v1alpha1nkind: AppProjectnmetadata:n  name: mijn-projectnspec:n  sourceIntegrity:n    - repositoryURL: https://git.voorbeeld.nl/repo.gitn      gnuPGPublicKeyIDs:n        - ABCD1234EFGH5678

Lees je resultaten uit de REST API via het oude verifyResult-veld? Dat is ook deprecated — gebruik het nieuwe, gestructureerde sourceIntegrityResult-veld.

2. TLS-configuratievlag hernoemd

argocd-server \n  --repo-server-strict-tls

argocd-server \n  --repo-server-ca-cert-path=/app/config/server/tls/ca.crt

De oude vlag blijft nog werken (met waarschuwing), maar geeft geen expliciet certificaatpad mee — de nieuwe aanpak is preciezer en toekomstvast.

3. Impersonatie geldt nu voor alle API-operaties, niet alleen sync

Dit is de wijziging met de meeste praktische impact als je impersonatie al gebruikt. Vóór 3.5 werd de geïmpersoneerde service-account (afgeleid van destinationServiceAccounts in je AppProject) alleen gebruikt tijdens sync-operaties. Vanaf 3.5 geldt dat voor élke API-server-operatie — logs bekijken, events opvragen, resources verwijderen, resource-acties uitvoeren, ook via de UI.

Examentip: Controleer vóór het upgraden of de geïmpersoneerde service-accounts in je AppProjects voldoende rechten hebben voor meer dan alleen sync — anders lopen teamleden na de upgrade opeens tegen 403-foutmeldingen aan bij heel gewone acties zoals logs bekijken.

4. Legacy Helm-versie-instellingen worden genegeerd

Had je ooit ergens expliciet een oudere Helm-binary-versie afgedwongen op je Application? Die instelling wordt in 3.5 simpelweg genegeerd — Argo CD gebruikt nu altijd Helm 4 om te renderen, punt. Er is bewust geen "blijf op Helm 3"-schakelaar.

5. REST-clients gegenereerd uit de OpenAPI-definitie

Gebruik je gegenereerde REST-clients (bijvoorbeeld voor eigen automatisering)? Behandel deze upgrade als een schema-brekende wijziging — regenereer of update je clients tijdens de upgrade.

De bredere Helm 4-context, voor wie Helm ook los van Argo CD gebruikt

Draai je naast Argo CD ook losse helm install/upgrade-commando's (bijvoorbeeld in CI/CD-scripts), dan gelden de bekendere Helm 4-breaking-changes wél voor jou:

• Post-renderers moeten Helm-plugins zijn — het direct aanroepen van een uitvoerbaar script (--post-renderer ./script.sh) werkt niet meer; registreer het script eerst als plugin via een plugin.yaml.
• helm registry login accepteert geen https://-prefix meer — alleen nog kale domeinnamen.
• Vlaggen hernoemd: --atomic → --rollback-on-failure, --force → --force-replace.
• --wait vereist nu het watch-RBAC-recht (via kstatus) — test dit vooraf met kubectl auth can-i watch pods --as=system:serviceaccount:jouw-namespace:helm.

Belangrijk: Helm 3 raakt niet abrupt onbruikbaar: Helm 4 (GA sinds 12 november 2025) neemt bestaande releases zonder migratiestap over — er is geen harde deadline om vandaag te upgraden. Wel een concrete horizon: reken op het einde van reguliere bugfixes voor Helm 3 rond medio 2026, met beveiligingsfixes die nog een aantal maanden langer doorlopen. Check bij een daadwerkelijke upgrade altijd de actuele, officiële Helm-documentatie voor de precieze, op dat moment geldende einddata — dit soort steunperiodes wordt weleens bijgesteld.

Praktisch stappenplan

1. Maak een back-up vóór een major/minor-upgrade (argocd admin export > backup-$(date +%Y%m%d).yaml) — standaardpraktijk bij elke Argo CD-upgrade, niet specifiek voor 3.5
2. Controleer of je GnuPG-signatuurverificatie gebruikt — zo ja, plan de migratie naar sourceIntegrity
3. Controleer of je --repo-server-strict-tls gebruikt — zo ja, migreer naar --repo-server-ca-cert-path
4. Gebruik je impersonatie? Controleer of de service-accounts breder dan alleen sync-rechten nodig hebben
5. Test eerst in een dev/staging-omgeving — dit is een minor-versie-upgrade, geen major, maar met écht breaking changes
6. Regenereer REST-clients die uit de OpenAPI-definitie zijn gegenereerd, indien van toepassing

Relevante Kennisbank-achtergrond

• Argo CD-architectuur: hoe de sync loop werkt →
• GitOps uitgelegd: Git als enige bron van waarheid →