Portées opérateur

Les portées d’opérateur définissent ce qu’un client Gateway peut faire après son authentification. Elles constituent un garde-fou du plan de contrôle dans un même domaine d’opérateur Gateway de confiance, et non une isolation multilocataire hostile. Si vous avez besoin d’une séparation forte entre des personnes, des équipes ou des machines, exécutez des Gateways séparés sous des utilisateurs système ou des hôtes distincts. Voir aussi : Sécurité, Protocole Gateway, Appairage Gateway, CLI des appareils.

​

Rôles

Les clients WebSocket Gateway se connectent avec un rôle :

• operator : clients du plan de contrôle tels que la CLI, l’interface Control UI, l’automatisation et les processus d’assistance de confiance.
• node : hôtes de capacités tels que macOS, iOS, Android ou des nœuds sans interface qui exposent des commandes via node.invoke.

Les méthodes RPC d’opérateur nécessitent le rôle operator. Les méthodes initiées par un nœud 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 possède operator.admin.

​

La portée de méthode n’est que le premier garde-fou

Chaque RPC Gateway possède une portée de méthode de moindre privilège. Cette portée de méthode décide si la requête peut atteindre le gestionnaire. Certains gestionnaires appliquent ensuite des contrôles plus stricts au moment de l’approbation, selon l’élément concret approuvé ou modifié. Exemples :

• device.pair.approve est accessible avec operator.pairing, mais l’approbation d’un appareil opérateur ne peut créer ou préserver que les portées que l’appelant détient déjà.
• node.pair.approve est accessible avec operator.pairing, puis dérive des portées d’approbation supplémentaires à partir de la liste de commandes de nœud en attente.
• chat.send est normalement une méthode à portée d’écriture, mais les commandes persistantes /config set et /config unset nécessitent operator.admin au niveau de la commande.

Cela permet aux opérateurs dotés de portées inférieures d’effectuer des actions d’appairage à faible risque sans rendre toutes les approbations d’appairage réservées aux administrateurs.

​

Approbations d’appairage d’appareil

Les enregistrements d’appairage d’appareil sont la source durable des rôles et portées approuvés. Les appareils déjà appairés n’obtiennent pas silencieusement un accès plus large : les reconnexions qui demandent un rôle ou des portées plus larges créent 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 de jeton d’opérateur.
• Une demande pour un rôle d’appareil non opérateur, tel que node, nécessite operator.admin, même lorsque device.pair.approve est accessible avec operator.pairing.
• Une demande pour operator.read, operator.write, operator.approvals, operator.pairing ou operator.talk.secrets nécessite que l’appelant détienne ces portées, ou operator.admin.
• Une demande pour operator.admin nécessite operator.admin.
• Une demande de réparation sans portées explicites peut hériter des portées de jeton d’opérateur existantes. Si ce jeton existant a une portée d’administration, l’approbation nécessite toujours operator.admin.

Les sessions à secret partagé et à proxy de confiance non administratrices peuvent approuver les demandes d’appareil opérateur uniquement dans leurs propres portées d’opérateur déclarées. L’approbation de rôles non opérateur est réservée aux administrateurs, même lorsque ces sessions peuvent par ailleurs utiliser operator.pairing. Pour les sessions avec jeton d’appareil appairé, la gestion est également limitée à soi-même, sauf si l’appelant possède operator.admin : les appelants non administrateurs ne voient que leurs propres entrées d’appairage, ne peuvent approuver ou rejeter que leur propre demande en attente, et ne peuvent effectuer une rotation, révoquer ou supprimer que leur propre entrée d’appareil.

​

Approbations d’appairage de nœud

L’ancien node.pair.* utilise un magasin d’appairage de nœuds séparé appartenant au Gateway. Les nœuds WS utilisent l’appairage d’appareil avec role: node, mais le même vocabulaire de niveau d’approbation s’applique. node.pair.approve utilise la liste de commandes de la demande en attente pour dériver les portées supplémentaires requises :

• Demande sans commande : operator.pairing
• Commandes de nœud hors exécution : operator.pairing + operator.write
• system.run, system.run.prepare ou system.which : operator.pairing + operator.admin

L’appairage de nœud établit l’identité et la confiance. Il ne remplace pas la politique d’approbation d’exécution system.run propre au nœud.

​

Authentification par secret partagé

L’authentification par jeton/mot de passe Gateway partagé est traitée comme un accès opérateur de confiance pour ce Gateway. Les surfaces HTTP compatibles OpenAI, /tools/invoke et les points de terminaison HTTP d’historique de session restaurent l’ensemble normal complet des portées d’opérateur par défaut pour l’authentification bearer par secret partagé, même si un appelant envoie des portées déclarées plus étroites. Les modes porteurs d’identité, tels que l’authentification par proxy de confiance ou none pour l’ingress privé, peuvent toujours respecter les portées déclarées explicites. Utilisez des Gateways séparés pour une véritable séparation des frontières de confiance.