feat(deploy): port interne, ConfigMap et NetworkPolicy de la CA dans le chart Helm

[PhilippeVienne]

PR empilée sur #19 (base : feat/lien-interne-ca-server) : elle utilise ca-server internal-cert et les variables OPENEIDAS_INTERNAL_* / OPENEIDAS_WEBAUTHN_* de cette PR. Indépendante de #20, #21 et #22. À rebrancher sur dev après le merge de #19 : gh api -X PATCH repos/open-eidas/open-eidas/pulls/N -f base=dev.

Contenu

Le lien interne de ca-server (/internal/v1/*, mTLS) devient déployable, en option et désactivé par défaut (ca.internal.enabled: false). Avec le défaut, le rendu du chart (y compris values-staging.yaml) est strictement inchangé.

Quand il est activé :

• ca.service.internalPort (8321) : second port du Service, jamais dans une HTTPRoute (une NetworkPolicy ne voit que les ports, docs/WEBUI.md §17) ;
• NetworkPolicy de la CA (la première du chart) : le port public reste ouvert au cluster (Gateway, enrôlement de la TSA et de l'OCSP, sondes du kubelet) ; le port interne n'est joignable que depuis les pods ra-console de la release. Tant qu'aucun pod ne porte ce composant, personne ne le joint ;
• ConfigMap de la liste blanche de modèles de clés d'opérateur, montée en lecture seule ;
• le rendu échoue si rpId, origin ou la liste de modèles manquent : un lien interne à moitié configuré n'est pas déployé ;
• entrypoint : au premier démarrage, dépose la demande de certificat internal_server et attend son approbation avant de démarrer. Le sidecar d'approbation la traite en démonstration ; en production, un opérateur nommé l'approuve (kubectl exec … ca-server ra approve, documenté dans le README du chart). La clé (0600, dossier 0700) et la demande survivent à un redémarrage ; les erreurs ne sont pas réessayées en boucle (seul le code 3, « en attente », l'est).

Points d'attention

• Le démarrage bloque tant que la demande n'est pas approuvée (10 min par défaut, OPENEIDAS_INTERNAL_CERT_ATTEMPTS), y compris l'API publique de la CA. C'est voulu pour le Jour 0 (serve refuse d'ouvrir le port interne sans certificat) ; en production sans sidecar, l'approbation se fait pendant ce temps. À discuter si on préfère démarrer sans le lien interne puis l'ouvrir plus tard.
• Le cluster doit faire appliquer les NetworkPolicy (CNI compatible). Sans cela, le port reste joignable du cluster ; le mTLS de ca-server reste exigé dans tous les cas.
• Le certificat n'est lu qu'au démarrage : le renouveler (3 mois) est manuel (supprimer server.pem, redémarrer). Documenté.
• Hors périmètre, noté dans TODO.md : valeurs raConsole.*, NetworkPolicy de ra-console et service ra-console du docker-compose.yml, qui attendent que le service existe.

Vérifications

• helm lint et helm template : défaut et staging inchangés (aucune ressource nouvelle) ; mode activé : Service, ConfigMap et NetworkPolicy attendus, aucune HTTPRoute ne mentionne le port interne ; échecs clairs sans rpId ni modèles.
• Entrypoint testé avec des commandes factices : deux attentes puis succès ; erreur immédiate sans boucle ; abandon après N tentatives ; aucune demande si le lien n'est pas configuré ; dossier de la clé en 0700.
• Image réelle construite depuis deploy/ca-server/Dockerfile (nouvelles dépendances rustls / ring comprises) et lancée avec PostgreSQL : le conteneur attend l'approbation, la reçoit, écrit le certificat, ouvre le lien interne en mTLS (mtls=true), l'API publique répond, le port interne refuse sans certificat client, et un redémarrage réutilise le certificat sans nouvelle demande. Aucun cluster n'a été touché.