Portées des opérateurs

Les portées d’opérateur déterminent ce qu’un client du Gateway peut faire après s’être authentifié. Elles constituent un garde-fou du plan de contrôle au sein d’un même domaine d’opérateur Gateway de confiance, et non une isolation hostile entre plusieurs locataires. Pour assurer une séparation forte entre des personnes, des équipes ou des machines, exécutez des Gateways distincts sous des utilisateurs du système d’exploitation ou sur des hôtes distincts.

Voir aussi : Sécurité, Protocole du Gateway, Appairage du Gateway, CLI des appareils.

Rôles

Chaque client WebSocket du Gateway se connecte avec un rôle :

• operator : clients du plan de contrôle tels que la CLI, l’interface de contrôle, les automatisations et les processus auxiliaires de confiance.
• node : hôtes de capacités (macOS, iOS, Android, sans interface graphique) qui exposent des commandes via node.invoke.

Les méthodes RPC d’opérateur nécessitent le rôle operator ; les méthodes provenant d’un Node nécessitent le rôle node.

Niveaux de portée

Les futures portées operator.* inconnues nécessitent une correspondance exacte, sauf si l’appelant dispose déjà de operator.admin.

La portée de la méthode n’est que le premier contrôle

Chaque RPC du Gateway possède une portée de méthode fondée sur le moindre privilège qui détermine si une requête atteint son gestionnaire. Certains gestionnaires appliquent ensuite des contrôles plus stricts selon l’élément concret approuvé ou modifié :

• device.pair.approve est accessible avec operator.pairing, mais l’approbation d’un appareil d’opérateur ne peut créer ou conserver que les portées que l’appelant possède déjà.
• node.pair.approve est accessible avec operator.pairing, puis déduit des portées d’approbation supplémentaires à partir de la liste de commandes déclarée par le Node en attente.
• chat.send est une méthode à portée d’écriture, mais les commandes de conversation /config set et /config unset nécessitent en plus operator.admin, quelle que soit la portée d’envoi de conversation de l’appelant.

Cela permet aux opérateurs disposant de portées limitées d’effectuer des actions d’appairage à faible risque sans réserver toutes les approbations d’appairage aux administrateurs.

Approbations d’appairage des appareils

Les enregistrements d’appairage des appareils constituent la source persistante des rôles et portées approuvés. Un appareil déjà appairé n’obtient pas silencieusement un accès plus étendu : une reconnexion demandant un rôle ou des portées plus étendus crée une nouvelle demande de mise à niveau en attente.

Lors de l’approbation d’une demande d’appareil :

• Une demande sans rôle d’opérateur ne nécessite pas d’approbation de portée d’opérateur.
• Une demande de rôle d’appareil autre qu’opérateur (par exemple node) nécessite operator.admin, même si device.pair.approve ne nécessite lui-même que operator.pairing.
• Une demande de operator.read, operator.write, operator.approvals, operator.pairing ou operator.talk.secrets nécessite que l’appelant dispose déjà de cette portée, ou de operator.admin.
• Une demande de operator.admin nécessite operator.admin.
• Une demande de réparation sans portées explicites peut hériter des portées du jeton d’opérateur existant ; si ce jeton possède une portée d’administration, l’approbation nécessite tout de même operator.admin.

Les sessions non administratrices utilisant un secret partagé ou un proxy de confiance ne peuvent approuver les demandes d’appareils d’opérateur que dans les limites de leurs propres portées d’opérateur déclarées ; l’approbation des rôles autres qu’opérateur est réservée aux administrateurs, même lorsque ces sessions peuvent par ailleurs utiliser operator.pairing.

Pour les sessions utilisant le jeton d’un appareil appairé, la gestion est limitée à l’appareil lui-même, sauf si l’appelant dispose de operator.admin : un appelant non administrateur ne voit que ses propres entrées d’appairage et ne peut approuver, rejeter, renouveler, révoquer ou supprimer que l’entrée de son propre appareil.

Approbations d’appairage des Nodes

Les anciennes méthodes node.pair.* utilisent un magasin d’appairage de Nodes distinct appartenant au Gateway. Les Nodes WS utilisent plutôt l’appairage d’appareils (role: node), mais le même vocabulaire d’approbation s’applique. Consultez Appairage du Gateway pour comprendre la relation entre les deux magasins.

node.pair.approve déduit les portées supplémentaires requises à partir de la liste de commandes de la demande en attente :

L’approbation d’une déclaration de Node n’active pas les commandes soumises à une liste d’autorisation d’exécution distincte. Par exemple, l’approbation d’un Node qui déclare computer.act nécessite la portée d’appairage et celle d’écriture, mais enregistre uniquement cette surface. Un administrateur ou un propriétaire doit toujours activer computer.act. Tant qu’elle reste activée, son invocation via la méthode node.invoke à portée d’écriture ne nécessite pas de portée d’administration pour chaque action.

L’appairage d’un Node établit son identité et la confiance qui lui est accordée ; il ne remplace pas la politique d’approbation des exécutions system.run propre au Node.

Authentification par secret partagé

L’authentification par jeton ou mot de passe partagé du Gateway est considérée comme un accès d’opérateur de confiance pour ce Gateway. Les surfaces HTTP compatibles avec OpenAI, /tools/invoke et les points de terminaison HTTP d’historique des sessions rétablissent l’ensemble complet des portées d’opérateur par défaut pour l’authentification par jeton porteur fondée sur un secret partagé, même si un appelant envoie des portées déclarées plus restreintes.

Les modes associés à une identité, tels que l’authentification par proxy de confiance ou none pour une entrée privée, peuvent toujours respecter les portées explicitement déclarées. Utilisez des Gateways distincts pour séparer de véritables frontières de confiance.