Le plan de contrôle

Tout ce à quoi la passerelle fait confiance arrive sous forme de fichier signé. obsign-control est l’endroit d’où ces fichiers viennent, et la raison pour laquelle un changement de règle est une pull request datée et revue.

Publier

# the source tree is a git checkout:
#   policies/*.cedar   tools.json   fail-mode.json   identity/{provider,jwks}.json
obsign-control publish \
    --source ~/acme-policies --key /tmp/ops.hex --key-id ops-2026 \
    --dist /srv/obsign/dist
# [control] compiled policies@847d4fca5754 — 1 rule file(s), 2 tool(s), ...
# [control] published release 847d4fca5754 -> /srv/obsign/dist/releases/847d4fca5754

La version est le sha du commit, résolu en lisant .git directement ; aucun binaire git n’est requis sur l’hôte de build. Chaque décision consignée dans le journal cite policies@<sha> ; la rejouer des mois plus tard revient à faire un checkout de ce sha.

La compilation valide avec les propres chemins de code de la passerelle : ce qui passe en CI ne peut pas échouer au démarrage à l’échelle de la flotte (syntaxe Cedar, @id obligatoire sur chaque règle, outils en double, surcharges de fail-mode nommant des outils inexistants, clés JWKS inutilisables ou interdites). Le JWKS est un fichier dans git, revu comme une règle : il décide de qui peut forger des identités.

La publication tient deux invariants :

• Une version est immuable — releases/<sha>/ est écrit une seule fois ; publier un contenu différent sous un sha existant est refusé. Un crash en cours de publication est réparé au passage suivant ; une source modifiée ne l’est pas.
• Les fichiers courants changent atomiquement — écriture puis renommage sur les fichiers que les passerelles rechargent à chaud : un lecteur voit l’ancienne release ou la nouvelle, jamais un fichier déchiré. Le rollback ne demande aucun outillage : republiez l’ancien sha.

Le manifeste de release est signé, mais les empreintes d’artefacts qu’il contient sont de simples SHA-256 des octets du fichier, délibérément : « le bundle que ma passerelle a chargé est-il celui que le manifeste nomme ? » doit pouvoir se répondre avec rien de plus que sha256sum.

Le dossier d’audit

obsign-ledger export produit un pack pour une chaîne ; un auditeur demande une période. Avec le transport HTTP, chaque session d’agent est sa propre chaîne : « qu’ont fait vos agents au T3 » représente donc des dizaines de packs :

obsign-control export \
    --wal /srv/obsign/wal --store /srv/obsign/ledger \
    --out /tmp/dossier --key /tmp/ops.hex --key-id ops-2026

Chaque chaîne est exportée, vérifiée au passage et listée dans un manifeste d’export signé. Le dossier ne peut donc pas perdre un pack en chemin sans que la perte soit visible. Un pack qui échoue à la vérification est écrit et signalé, jamais réparé ni filtré : un export qui arrangerait les choses en chemin ferait exactement ce que le produit existe pour rendre impossible. Le code de sortie le dit.

La console

obsign-control console \
    --wal /srv/obsign/wal --store /srv/obsign/ledger --dist /srv/obsign/dist

Trois pages HTML rendues côté serveur sur std::net : la release courante avec son verdict de signature, les chaînes avec leur état de scellement (chacune revérifiée à la demande), les enregistrements. Pas de JavaScript, pas de moteur de templates, pas de cache : ce que la console montre est ce que les fichiers disent maintenant.

En lecture seule par construction. La seule méthode acceptée est GET, si bien que la console ne peut jamais devenir un second chemin d’écriture contournant git. Elle écoute sur localhost par défaut ; l’authentification relève de la couche commerciale.