feat(deploy): image, chart Helm et surcouche compose de ra-console

[PhilippeVienne]

Objet

TODO §1, docs/WEBUI.md §16-17 : rendre ra-console déployable, sans changement de son code Rust. Empilée sur #67 (feat/ra-console-quorum) → #66 → #65 → #64. Ordre de merge : #64, #65, #66, #67, cette PR.

• Image deploy/ra-console/Dockerfile : cargo build -p ra-console seul (l'unification des features du workspace réactiverait cryptoki ; no_pkcs11.rs en est la garde), ni SoftHSM ni opensc, utilisateur non-root 10004. Ajoutée aux matrices construction + scan Trivy et publication GHCR (open-eidas-ra-console, image par défaut du chart). La vérification « le binaire démarre » accepte --version (la console n'a ni PIN ni sous-commande version).
• Entrypoint : au premier démarrage, récupère le certificat de la CA émettrice (/api/v1/ca.pem de l'API interne de la CA, premier certificat = émettrice, conservé ensuite), puis ra-console internal-cert, qui attend l'approbation (sidecar en démo, opérateur nommé en production).
• Helm, raConsole.enabled: false par défaut (aucun déploiement existant ne change, hormis deux clés ajoutées au Secret généré) ; rendu refusé si raConsole.enabled sans ca.internal.enabled. Réutilise la Relying Party WebAuthn et la liste blanche de modèles de la CA (une seule configuration). Deployment (volume d'état RWO, sondes : prête = base + lien, vivante = écoute), Service, HTTPRoute optionnelle (Gateway interne), NetworkPolicy (entrée : namespace de la Gateway seul ; sortie : DNS, PostgreSQL, CA ports public et interne).
• Droits PostgreSQL : Job hook post-install/post-upgrade (image postgres) qui attend les migrations de ca-server, applique ra_console_grants.sql et pose le mot de passe du rôle (par variable psql, jamais en ligne de commande). Pourquoi un Job et pas un initContainer : les identifiants d'administration de la base n'entrent jamais dans le pod de la console, le composant le plus exposé (§16). Rejoué à chaque mise à jour : les nouveaux droits (ex. SELECT sur actions, feat(ra-console): double contrôle, co-signature et salle d'attente (étape 4b) #67) arrivent sans geste manuel. Le script est copié dans files/ (Helm ne lit rien hors du chart) ; la CI vérifie qu'il est identique à l'original. Un initContainer de la console attend son rôle avec ses propres identifiants.
• docker-compose : surcouche opt-in docker-compose.console.yml (lien interne de la CA, service one-shot des droits, console), jamais chargée par make up ni par la CI : elle exige une liste blanche de modèles (deploy/ra-console/models.json) qu'aucune valeur par défaut ne peut fournir. Le docker-compose.yml de la démo n'est pas modifié.
• CI / make helm-lint : lint et rendu avec ci/ra-console-values.yaml, refus sans lien interne, identité du script des droits. .helmignore exclut ci/ du chart.
• Docs : README du chart (section console, valeurs), docs/RA-CONSOLE.md (déploiement, variables complètes).

Décisions à valider

• Publication GHCR de la nouvelle image à chaque push sur dev (sinon l'image par défaut du chart n'existe pas). Un package GHCR créé par GITHUB_TOKEN peut naître privé (voir le commentaire du job publish). Pas d'épinglage sur le staging.
• Base externe (CloudNativePG) : le Job exige que postgres.user puisse créer un rôle (CREATEROLE) ; à vérifier sur otspi/deploy avant d'activer la console en staging.
• OPENEIDAS_ENROLL_HMAC_KEY dans le pod de la console (nécessaire à internal-cert) : une console compromise pourrait déposer des demandes d'enrôlement — qui restent soumises à approbation, comme pour la TSA.
• Confiance initiale dans le certificat de la CA : récupéré en HTTP sur le réseau du cluster, par le même canal que l'enrôlement (TOFU), puis conservé.
• Sondes du kubelet et NetworkPolicy d'entrée vide sans Gateway : la plupart des CNI laissent passer le trafic du nœud (sondes) ; à confirmer sur le CNI du cluster cible.

Limites

• Aucun job de démonstration réelle (kind, compose) ne déploie la console : non branchée, faute de pouvoir le vérifier ici de bout en bout (liste blanche de modèles, approbation du certificat client).
• Le Job des droits n'a pas été exécuté contre un vrai cluster ; seule l'interpolation psql du mot de passe a été vérifiée contre PostgreSQL 17.

Vérifications

• helm lint et helm template : défaut, avec la console (ci/ra-console-values.yaml, avec et sans Gateway), cas de refus ; 26 documents rendus relus par un analyseur YAML. make helm-lint vert.
• Mutation de la garde : sans le fail, make helm-lint échoue. Le premier jet du contrôle ne l'aurait pas vu (le rendu échouait déjà faute de rpId) : le cas de refus fournit désormais des valeurs complètes, seule la garde peut le faire échouer.
• docker build -f deploy/ra-console/Dockerfile . : OK ; --version OK ; ldd : seules libssl/libcrypto/libc ; utilisateur ra (10004) ; l'entrypoint refuse clairement sans configuration. Trivy non disponible ici (la CI le lance).
• docker compose -f docker-compose.yml [-f docker-compose.console.yml] config -q : OK.
• YAML de la CI valide (matrices build et publish à quatre images).
• cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings (1.97 et 1.98.1), cargo test -p ra-console avec PostgreSQL (dont no_pkcs11.rs) : verts.

Revue humaine obligatoire

Voir PROVENANCE.md. Chaque case est cochée par le
contributeur humain qui valide la PR, après l'avoir fait lui-même.

• Revue d'architecture validée par l'humain
• Code relu et tests unitaires/intégration vérifiés localement
• Absence de dépendances tierces incompatibles avec la double licence EUPL-1.2 / AGPL-3.0 (make licenses)
• Validation de l'apport intellectuel et de la paternité humaine sur la modification

Assistance par IA

• Cette PR a été produite avec l'assistance de Claude Code : les commits concernés portent la remorque Co-authored-by: Claude <noreply@anthropic.com>, auteur et committer restent humains, et scripts/provenance.py archive a été lancé
• Cette PR a été écrite sans assistance par IA

[gitguardian]

⚠️ GitGuardian has uncovered 4 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
37113203	Triggered	Generic Password	4934b57	deploy/helm/open-eidas/templates/secrets/generated.yaml	View secret
37665449	Triggered	Generic Password	4934b57	docker-compose.console.yml	View secret
37665552	Triggered	Generic Password	01bf013	docker-compose.console.yml	View secret
37113205	Triggered	Generic Password	4934b57	docker-compose.console.yml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}