Workbench Console

Console opérateur autonome des Ateliers Asami.

Architecture

• développement/qualification possible dans un Atelier ;
• cible d'exécution : conteneur indépendant sur Hiko-Seijuro ;
• aucune dépendance au Docker socket ;
• aucune clé SSH dans le navigateur ;
• configuration des Ateliers montée en lecture seule ;
• les upstreams Asami/WMI restent des services externes ;
• le déploiement Hiko utilise restart: unless-stopped et un worktree rolling read-only.

Frontière HTTPS + mTLS entrante

Workbench Console ne termine pas TLS. nginx le fait.

L'application refuse cependant chaque requête si les trois preuves suivantes ne sont pas réunies :

1. le pair TCP est exactement WORKBENCH_TRUSTED_PROXY_IP ;
2. X-Forwarded-Proto vaut exactement https ;
3. X-SSL-Client-Verify vaut exactement SUCCESS.

Le host doit également correspondre à WORKBENCH_PUBLIC_URL.

Uvicorn est lancé avec --no-proxy-headers afin que le pair TCP ne soit jamais réécrit à partir de X-Forwarded-For.

Le healthcheck Docker est un probe TCP local et n'introduit aucun endpoint HTTP non authentifié.

Accès sortant aux WMI

Les Ateliers actifs sont sondés à partir de leur unique wmi_url, sur les VHosts HTTPS réels de Terry. Workbench Console ne contacte pas directement les ports WMI 8098 et ne synthétise jamais les headers d'attestation mTLS/trusted-proxy.

Lorsqu'un bloc upstream_tls est configuré, le client HTTP construit un contexte TLS serveur strict avec l'identité robot WCons :

{
  "upstream_tls": {
    "client_cert": "/run/workbench/pki/client-fullchain.pem",
    "client_key": "/run/workbench/pki/client.key"
  }
}

Le certificat/clé sont des fichiers de déploiement hors Git, montés en lecture seule. La validation du certificat serveur utilise le trust store système ; il n'existe pas de mode verify=false dans la configuration applicative.

Déploiement rolling Hiko-Seijuro

Layout hôte canonique :

/home/docker/workbench-console/
├── compose.yaml
├── source/     # checkout Git
├── config/     # configuration montée ro
├── data/       # seul état applicatif hôte monté rw
└── pki/        # identité robot mTLS, montée ro

Le conteneur monte uniquement source/src en lecture seule et place ce chemin en tête de PYTHONPATH. Uvicorn surveille /workspace/src avec --reload. Une modification Python recharge donc automatiquement le worker ; les fichiers HTML/CSS/JS statiques sont lus directement depuis le worktree monté.

Un changement de dépendances Python ou de Dockerfile nécessite un rebuild d'image. Le code applicatif ordinaire n'en nécessite pas.

Le port hôte par défaut est 8099. WORKBENCH_BIND_IP peut être fixé à l'adresse LAN de Hiko ou laissé à 0.0.0.0 puisque le reverse proxy est distant. L'application reste fail-closed sur le peer TCP du proxy, HTTPS attesté, mTLS attesté et Host.

Le Compose exige le GID opérateur WORKBENCH_PKI_GID (actuellement 121, dérivé du groupe admin sur Hiko) uniquement pour permettre la lecture de pki/client.key en 0640; aucune capacité Linux supplémentaire ni accès Docker n'est accordé.