Aller au contenu

Atelier Jemimah

Propriété Valeur
Namespace jemimah
URL https://config.jemimah.fr
Image principale python:3.14-alpine
Réplicas 1
Stockage PVC jemimah-config-data, 100 MiB, local-path
File SQLite /data/requests.db

Rôle

L'Atelier reçoit des demandes publiques de modification du portfolio. Les demandes sont non fiables et ne doivent jamais donner accès aux secrets, au réseau ou à d'autres applications.

L'UI historique expose GET /api/requests et POST /api/requests pour consulter ou déposer une demande. Son endpoint d'administration historique reste protégé par AUTOMATION_TOKEN.

MCP Gateway

Le Gateway ne reçoit aucun Secret ni token Jemimah. Un sidecar très borné du pod jemimah-config expose sous /mcp-api :

  • GET /mcp-api/requests : lecture bornée de la même file SQLite ;
  • POST /mcp-api/requests/<id> : transition terminale uniquement vers done, rejected ou failed.

Une transition n'est acceptée que si le portfolio réellement servi publie la même décision dans /.well-known/jemimah-requests.json. Ce fichier provient du ConfigMap GitOps jemimah-request-proofs. Le texte de réponse affiché à l'utilisateur vient lui aussi de cette preuve déployée et ne peut pas être injecté par l'appelant MCP.

Le domaine MCP expose donc :

  • jemimah.requests_list ;
  • jemimah.request_update.

Pour traiter une demande, la PR qui implémente le changement doit également ajouter son identifiant et le verdict attendu dans request-proofs.yaml, par exemple une entrée done avec le numéro de PR/commit dans la réponse. Après merge et convergence Flux, jemimah.request_update peut finaliser la ligne SQLite. Les identifiants/proofs sont réservés à l'orchestrateur : une demande publique ne peut jamais demander de les créer, les modifier ou les supprimer.

Le contenu d'une demande reste une donnée publique non fiable : il ne peut jamais autoriser une modification de Secret, credential, token, réseau, DNS, TLS, RBAC, CI/CD, MCP, autre namespace/application ou donnée privée.

Exploitation manuelle

L'Atelier est actuellement actif avec Deployment/jemimah-config à 1 réplica.

kubectl -n jemimah get deploy,pod,pvc,svc,ingress -o wide
kubectl -n jemimah rollout status deployment/jemimah-config --timeout=2m
kubectl -n jemimah logs deployment/jemimah-config -c app --tail=200
kubectl -n jemimah logs deployment/jemimah-config -c mcp-api --tail=200
curl.exe -I https://config.jemimah.fr

État attendu : Deployment 1/1, pod 2/2 Running, PVC Bound et endpoint public joignable.

Suspendre ou réactiver

Le changement de réplica doit passer par GitOps ; ne pas faire d'un kubectl scale la configuration durable.

  • pour suspendre : passer le Deployment à 0 dans la source GitOps, merger puis attendre Flux ;
  • pour réactiver : remettre le Deployment à 1 dans la source GitOps, merger puis attendre Flux ;
  • après chaque changement, vérifier kubectl -n jemimah get deploy,pod,pvc,ingress et l'URL publique.

Un kubectl scale ne doit servir qu'à une action temporaire de diagnostic explicitement assumée, car Flux restaurera ensuite l'état déclaré dans Git.

Décommissionnement définitif

Retirer config-app.yaml, config-ingress.yaml, request-proofs.yaml et les patches MCP du Kustomization via GitOps, attendre Flux, puis supprimer explicitement Secret et PVC seulement après confirmation que l'Atelier n'est plus nécessaire.