L’assunzione che il repo-server di Argo CD sia sicuro solo perché “interno” non regge: se quel servizio è raggiungibile, il controllo del flusso di deploy può diventare esecuzione di comandi e poi compromissione del cluster. Il punto debole non è un singolo pod, ma la fiducia riposta in una superficie gRPC senza autenticazione, che in molte installazioni Helm resta esposta perché le network policy sono disattivate.
Synacktiv ha mostrato l’abuso su Argo CD v2.13.3: una richiesta alla service interna GenerateManifest può far eseguire a kustomize uno script invece del binario previsto, con un comando scelto dall’attaccante. Da lì è stato possibile leggere la password Redis di Argo CD e avvelenare i dati di sync, fino a ottenere il rilascio di workload controllati dall’attaccante; il problema resta senza fix e senza CVE dopo circa 18 mesi dalla segnalazione.
Per gli operatori Kubernetes, la lezione è che un servizio di control plane “interno” non va trattato come innocuo per posizione di rete. Se la reachability verso repo-server esiste, la compromissione può propagarsi lungo il meccanismo di sync di Argo CD e trasformarsi in takeover della flotta gestita.