Dix-huit mois sans correctif : comment une faille dans Argo CD a exposé tout le cluster Kubernetes

6 Min. Temps de lecture

Depuis 18 mois, une faille est présente dans le serveur Argo-CD Repo, pour laquelle il n’existe toujours pas de patch ni même de numéro CVE. Le service gRPC interne ne vérifie pas l’identité. Quiconque l’atteint dans le cluster peut exécuter des commandes, empoisonner le cache Redis et déployer ses propres workloads lors de la prochaine synchronisation. Un seul pod compromis suffit.

Les points clés en bref

• Pas de patch, pas de CVE : Synacktiv a signalé l’erreur en janvier 2025 aux mainteneurs d’Argo-CD et a publié les détails le 1er juillet 2026. Un correctif est toujours attendu.
• Le serveur Repo est la porte d’entrée : Son service gRPC fonctionne sans authentification. Un attaquant peut exécuter du code de manière non authentifiée via une option Kustomize préparée.
• La défense se situe dans le réseau : Les politiques de réseau Kubernetes isolent le serveur Repo et Redis. Argo CD fournit les règles, mais elles sont désactivées par défaut dans les installations Helm.

Lié :Gestion de Kubernetes dans les environnements multi-cloud  /  Ce que l’upgrade de Cilium peut faire dans le cluster

Ce que Synacktiv a trouvé dans le serveur Repo

Le serveur Repo est le composant qui permet à Argo CD de faire son travail. Il lit les référentiels Git et construit les manifestes Kubernetes finis. Pour que les autres composants Argo puissent l’interroger, il propose un point de terminaison gRPC interne. Ce point de terminaison ne demande pas d’identité. Tout processus qui l’atteint via le réseau peut lui envoyer des requêtes.

C’est précisément ici que l’attaque des chercheurs en sécurité de Synacktiv commence. Argo CD appelle l’outil standard Kustomize pour la construction de manifestes. Kustomize connaît une option qui permet de définir le chemin vers le binaire Helm. Via une requête préparée, cette option pointe vers une commande arbitraire. Le résultat est une exécution de commande non authentifiée au milieu de la chaîne de déploiement.

Le chemin ne se termine pas au serveur Repo. Les chercheurs ont lu le mot de passe Redis à partir d’une variable d’environnement, se sont connectés au cache Argo-CD et ont manipulé les données de déploiement stockées. Lors de la prochaine synchronisation automatique, Argo CD a déployé le workload sous-évalué. À partir d’un accès en lecture à un service auxiliaire, le contrôle sur l’ensemble du cluster est ainsi obtenu.

Pourquoi un outil de déploiement devient la clé du cluster

GitOps a des arguments solides. L’état souhaité est stocké dans Git, un contrôleur compare en permanence cet état avec le cluster en cours d’exécution. C’est traçable, versionné, sans bidouillage manuel avec kubectl. Le prix de cette commodité est rarement représenté dans le diagramme d’architecture : qui contrôle le chemin de déploiement contrôle tout ce qui se trouve à la fin de ce chemin.

Argo CD décide quels conteneurs sont déployés en production. Il détient les informations d’identification nécessaires pour la comparaison. Par définition, il a un droit d’écriture sur le cluster. Un attaquant qui prend le contrôle de cette machinerie n’a plus besoin de pirater une application individuelle. Il se configure lui-même dans l’état souhaité et laisse le contrôleur faire le travail sale.

C’est pourquoi des experts, comme dans ce cas, soutiennent que l’infrastructure GitOps devrait être traitée comme un élément de niveau 0. C’est-à-dire au même niveau de protection que le système d’identité ou l’autorité de certification. Pas comme un simple outil de déploiement de second rang, mais comme ce qu’il est : le centre de contrôle de la production.

Cinq étapes pour sécuriser le serveur de dépôt dès maintenant

Attendre un correctif du fabricant n’est pas une option, car il n’y en a pas. La bonne nouvelle : l’attaque nécessite un accès réseau au serveur de dépôt. C’est précisément là qu’il peut être arrêté.

1. Activer les NetworkPolicies. Argo CD fournit des règles prêtes à l’emploi qui n’autorisent que ses propres composants à accéder au serveur de dépôt et à Redis. Dans les installations Helm, elles sont désactivées. Les activer est la mesure la plus efficace.
2. Segmenter le serveur de dépôt et Redis. Les deux ports doivent être placés dans un segment de réseau dédié. Aucun autre pod du cluster n’a besoin d’y accéder.
3. Vérifier l’exposition. Contrôler quelles charges de travail peuvent aujourd’hui accéder au port gRPC. Dans les configurations Helm standard, c’est souvent l’ensemble du cluster.
4. Réévaluer les paramètres par défaut des charts. Le cas montre un modèle : des options sécurisées sont proposées, mais désactivées. Cela s’applique au-delà d’Argo CD à de nombreux charts Helm.
5. Observer le comportement de synchronisation. Les déploiements inattendus ou les modifications de l’état souhaité sont des signaux d’alarme. Quiconque manipule le cache Redis laisse des traces dans la comparaison.

Installation standard vs. configuration sécurisée

La différence entre être vulnérable et sécurisé ne réside pas dans un nouveau composant, mais dans les paramètres que l’on doit connaître et configurer.

Ce que les administrateurs doivent retenir de ce cas

La véritable leçon ne se trouve pas dans Argo CD, mais dans l’hypothèse sous-jacente. Les services internes sont longtemps considérés comme dignes de confiance parce qu’ils se trouvent derrière la frontière du cluster. Le point de terminaison gRPC sans authentification est la conséquence logique de cette hypothèse. Elle n’est plus valable dès qu’un seul pod du même réseau est compromis.

Ceux qui pratiquent GitOps devraient traiter le centre de contrôle comme les portes de la salle des serveurs. Segmenté, surveillé, avec des règles explicitement définies plutôt que des paramètres par défaut hérités. Le correctif pour cette faille manque encore. La maîtrise de son propre réseau n’appartient à personne qui ne la prend pas.

Foire aux questions

Source de l’image de titre : Générée par IA (juillet 2026)