fix(argocd): trust private CA in repo-server for oci helm dependencies

[KepoParis]

Issues liées

Issues numéro:

---

Quel est le comportement actuel ?

Une Application dont le chart déclare une dépendance oci:// sur un registre signé par la CA privée échoue au rendu :

helm dependency build failed exit status 1: Error: could not download
oci://registry.<domaine>/<projet>/<chart>: tls: failed to verify certificate:
x509: certificate signed by unknown authority

helm dependency build résout les dépendances oci:// avec son propre client, qui valide le TLS contre le magasin de confiance du conteneur. Ce client ne lit pas argocd-tls-certs-cm, où 10-exposed-ca.j2 écrit pourtant déjà la CA privée. Les repo-creds ne portent que l'authentification, jamais de CA.

Quel est le nouveau comportement ?

Le chart monte déjà argocd-tls-certs-cm dans /app/config/tls. On ajoute ce chemin à SSL_CERT_DIR sur le repo-server. Go charge tous les fichiers des répertoires listés, la CA entre donc dans le magasin de confiance du processus et helm la voit.

/etc/ssl/certs reste en premier pour conserver les racines publiques, les pulls quay.io et docker.io ne changent pas.

Le bloc est placé sous le garde dsc.exposedCA.type != 'none' existant. Sans CA privée, rien ne change.

Cette PR introduit-elle un breaking change ?

Non.

Test sur MI Integ

• printenv SSL_CERT_DIR dans le repo-server renvoie /etc/ssl/certs:/app/config/tls
• helm pull oci://registry.<domaine>/<projet>/<chart> ne renvoie plus d'erreur x509
• Le même pull avec env -u SSL_CERT_DIR échoue toujours en tls: failed to verify certificate

Autres informations

roles/combine/tasks/main.yaml fusionne les fichiers de values avec list_merge='append'. La clé repoServer.env s'ajoute donc aux variables proxy de 10-proxy.j2 au lieu de les écraser.

Vérifier avec openssl s_client depuis le conteneur induit en erreur. OpenSSL lit bien SSL_CERT_DIR mais cherche des liens nommés par hash, absents d'un montage de ConfigMap. Il renvoie donc toujours verify error:num=19 alors que helm fonctionne. Le test valable est helm pull.

Après ce correctif le pull renvoie 401 Unauthorized. C'est la couche suivante, pas le TLS. Si le registre n'est pas le Harbor du socle, il faudra un repo-creds dédié dans templates/repo-creds.yml.j2, sur le modèle de oci-harbor-creds corrigé en #1087.