Architecture

Lisez cette page pour planifier en fonction de ce que le client installe sur une machine et de ce qui franchit la frontière de la machine.

Ce qui tourne sur la machine

Ici, une machine désigne le système d’exploitation sur lequel tournent les agents. Dans la plupart des parcs, c’est un poste de développeur, et c’est tout autant un bureau virtuel, un hôte de build ou une image de conteneur, partout où un agent est lancé. Si des agents y tournent, le client y est installé.

OpenLatch installe une seule chose sur une telle machine : le client OpenLatch. Il est installé une fois et couvre chaque agent de cette machine. Rien à placer devant l’agent, aucun service à monter à côté, aucun second produit à tenir synchronisé avec le premier.

Point	Détail
Ce qui est installé	Le client OpenLatch, une fois par système d’exploitation qui exécute des agents
Privilèges	S’installe et s’exécute au niveau de l’utilisateur. Aucun droit d’administrateur n’est requis, ni à l’installation ni ensuite
Posture réseau	N’écoute que sur l’interface de bouclage. Aucun port entrant n’est ouvert, et rien sur la machine n’est joignable depuis le réseau
Fichiers	Le client conserve sa configuration et ses enregistrements locaux dans un seul répertoire : ~/.openlatch sur macOS et Linux, %APPDATA%\openlatch sur Windows. OPENLATCH_DIR le déplace
Démarrage	Démarre avec la session de l’utilisateur, sous le gestionnaire de services du système d’exploitation
Où les décisions sont prises	Sur la machine, avant que l’action ne s’exécute. La console n’est pas sur ce chemin
Perte de connectivité	Continue de fonctionner. Les politiques restent en vigueur, et les enregistrements sont conservés jusqu’à ce que la console soit de nouveau joignable

Figure 1. Vue de déploiement : le client sur chaque machine, et la console en tant que service.

La console

La console est fournie en tant que service à app.openlatch.ai. Rien à installer, rien à héberger. Les données de votre organisation sont stockées séparément de celles de toutes les autres organisations.

La console porte quatre éléments avec lesquels vous travaillez : l’organisation, ses utilisateurs et leurs rôles, le registre des agents et le journal d’audit. Le registre des agents liste chaque machine connectée et les agents qui s’y trouvent, chacun avec un propriétaire et un niveau de contrôle : Enforced, Monitored ou Known. Le journal d’audit est en ajout seul et exportable, avec une durée de conservation que vous définissez. Configurer l’organisation décrit la procédure pour tout cela.

Les politiques sont rédigées dans la console, et de là elles atteignent chaque machine. Rédiger une Agent Intent Policy couvre la rédaction.

Comment une action est décidée

Une action produit un verdict, sur la machine, avant que l’action ne s’exécute. La console n’est pas sur ce chemin.

Étape	Ce qui se passe	Ce que vous pouvez observer
1 · L’agent propose l’action	L’agent s’apprête à lancer une commande shell ou à appeler un outil. Il remet d’abord l’action proposée à OpenLatch, et patiente	—
2 · OpenLatch décide sur la machine	La décision est prise au regard des politiques que la machine détient déjà. Aucun appel réseau et aucun modèle sur ce chemin	Un verdict est rendu que la console soit joignable ou non
3 · Le verdict revient à l’agent	Le verdict revient sous la forme que l’agent comprend, avec sa raison. Quand plusieurs politiques correspondent, la plus restrictive l’emporte	Sur un Block, le développeur voit le refus et sa raison dans l’agent, et l’action ne s’exécute pas
4 · Le résultat est enregistré	L’action et son verdict sont consignés sur la machine puis envoyés à la console. L’envoi est hors du chemin de décision : une console lente change le moment où une action est vue, jamais ce qui a été décidé	La machine, ses agents et leurs actions décidées apparaissent dans le registre des agents de la console

Figure 2. Une action, un verdict : la décision est prise sur la machine avant que l’action ne s’exécute, et l’enregistrement suit.

Ce qui franchit la frontière de la machine

Quatre flux franchissent la frontière d’une machine qui exécute le client. Deux seulement concernent OpenLatch.

Flux	Sens et contenu
Politiques	Descendant, de la console vers la machine. Le client vérifie au démarrage puis à intervalles réguliers s’il existe des politiques plus récentes que celles qu’il détient
Enregistrements	Montant, de la machine vers la console, en HTTPS et à travers votre proxy, une fois l’action déjà décidée
Le trafic de modèles de vos agents	Inchangé. Vos agents atteignent leurs points d’accès de modèles exactement comme avant, avec leurs propres identifiants, et OpenLatch ne modifie pas ce trafic
Connexion à la console	Vers la console depuis un navigateur, à travers votre fournisseur d’identité

Exigences réseau liste chaque destination et couvre les proxys et l’inspection TLS.

Quand le réseau est indisponible

Une console injoignable est un problème d’acheminement, pas un problème d’application. Les politiques déjà présentes sur la machine restent en vigueur, et la machine continue de décider avec elles aussi longtemps que dure la coupure. Les enregistrements qui ne peuvent pas être envoyés sont conservés localement, jusqu’à une limite de taille, et remontent quand la console redevient joignable. Une coupure assez longue pour dépasser la limite abandonne les enregistrements non envoyés les plus anciens, et le client le consigne.

Les politiques n’expirent pas d’elles-mêmes. Une politique qui se désactiverait après une coupure permettrait à n’importe qui de désactiver l’application en débranchant un câble : la machine continue donc d’appliquer, et la console montre que les politiques de la machine sont périmées. Une machine qui n’a jamais reçu de politique autorise l’action et consigne qu’elle n’avait pas de politique : OpenLatch ne bloque jamais sans politique. Exigences réseau donne le tableau complet des états dégradés.

Figure 3. Décider hors ligne : la machine continue de décider avec les politiques qu’elle détient, et les enregistrements attendent le réseau.

En bref

• Un client par machine qui exécute un agent, au niveau de l’utilisateur, sans droits d’administrateur. Il n’écoute que sur le bouclage et n’ouvre aucun port entrant.
• Il conserve sa configuration et ses enregistrements locaux dans un seul répertoire, ~/.openlatch ou %APPDATA%\openlatch, que OPENLATCH_DIR déplace.
• Les actions sont décidées sur la machine, avant de s’exécuter, au regard des politiques que la machine détient déjà. Aucun appel réseau sur ce chemin.
• La console est un service, rien à installer ni à héberger. Elle porte l’organisation, ses utilisateurs et leurs rôles, le registre des agents et le journal d’audit, et les politiques atteignent chaque machine depuis elle.
• Une console injoignable n’arrête pas l’application. Les politiques restent en vigueur, les enregistrements sont conservés et envoyés plus tard, et une machine sans politique autorise l’action et consigne pourquoi.