Gateway

Ambiti dell'operatore

Gli ambiti operatore definiscono cosa può fare un client Gateway dopo l'autenticazione. Sono una protezione del piano di controllo all'interno di un dominio operatore Gateway attendibile, non un isolamento multi-tenant ostile. Se serve una separazione forte tra persone, team o macchine, esegui Gateway separati con utenti OS o host separati.

Correlati: Sicurezza, protocollo Gateway, pairing Gateway, CLI dispositivi.

Ruoli

I client WebSocket Gateway si connettono con un ruolo:

operator: client del piano di controllo come CLI, Control UI, automazione e processi helper attendibili.
node: host di capability come macOS, iOS, Android o nodi headless che espongono comandi tramite node.invoke.

I metodi RPC dell'operatore richiedono il ruolo operator. I metodi originati dal nodo richiedono il ruolo node.

Livelli di ambito

Ambito	Significato
`operator.read`	Stato in sola lettura, elenchi, catalogo, log, letture di sessione e altre chiamate del piano di controllo non mutanti.
`operator.write`	Azioni operatore mutanti normali, come inviare messaggi, invocare strumenti, aggiornare impostazioni talk/voice e relay dei comandi del nodo. Soddisfa anche `operator.read`.
`operator.admin`	Accesso amministrativo al piano di controllo. Soddisfa ogni ambito `operator.*`. Richiesto per mutazioni della configurazione, aggiornamenti, hook nativi, namespace riservati sensibili e approvazioni ad alto rischio.
`operator.pairing`	Gestione del pairing di dispositivi e nodi, inclusi elenco, approvazione, rifiuto, rimozione, rotazione e revoca di record di pairing o token dispositivo.
`operator.approvals`	API di approvazione exec e plugin.
`operator.talk.secrets`	Lettura della configurazione Talk con i segreti inclusi.

Gli ambiti futuri sconosciuti operator.* richiedono una corrispondenza esatta, a meno che il chiamante non abbia operator.admin.

L'ambito del metodo è solo il primo controllo

Ogni RPC Gateway ha un ambito di metodo con privilegio minimo. Tale ambito di metodo decide se la richiesta può raggiungere l'handler. Alcuni handler applicano poi controlli più restrittivi al momento dell'approvazione in base all'elemento concreto che viene approvato o mutato.

Esempi:

device.pair.approve è raggiungibile con operator.pairing, ma l'approvazione di un dispositivo operatore può solo creare o preservare ambiti che il chiamante possiede già.
node.pair.approve è raggiungibile con operator.pairing, poi deriva ambiti di approvazione extra dall'elenco dei comandi del nodo in sospeso.
chat.send è normalmente un metodo con ambito di scrittura, ma /config set e /config unset persistenti richiedono operator.admin a livello di comando.

Questo consente agli operatori con ambiti inferiori di eseguire azioni di pairing a basso rischio senza rendere tutte le approvazioni di pairing riservate agli amministratori.

Approvazioni di pairing dei dispositivi

I record di pairing dei dispositivi sono la fonte durevole dei ruoli e degli ambiti approvati. I dispositivi già associati non ottengono silenziosamente un accesso più ampio: le riconnessioni che richiedono un ruolo più ampio o ambiti più ampi creano una nuova richiesta di upgrade in sospeso.

Quando si approva una richiesta di dispositivo:

Una richiesta senza ruolo operatore non richiede l'approvazione dell'ambito del token operatore.
Una richiesta per un ruolo dispositivo non operatore, come node, richiede operator.admin, anche quando device.pair.approve è raggiungibile con operator.pairing.
Una richiesta per operator.read, operator.write, operator.approvals, operator.pairing o operator.talk.secrets richiede che il chiamante possieda tali ambiti, oppure operator.admin.
Una richiesta per operator.admin richiede operator.admin.
Una richiesta di riparazione senza ambiti espliciti può ereditare gli ambiti del token operatore esistente. Se quel token esistente ha ambito admin, l'approvazione richiede comunque operator.admin.

Le sessioni non admin con segreto condiviso e proxy attendibile possono approvare richieste di dispositivi operatore solo entro i propri ambiti operatore dichiarati. L'approvazione di ruoli non operatore è riservata agli admin anche quando tali sessioni possono altrimenti usare operator.pairing.

Per le sessioni con token di dispositivi associati, anche la gestione è limitata a sé stesse a meno che il chiamante non abbia operator.admin: i chiamanti non admin vedono solo le proprie voci di pairing, possono approvare o rifiutare solo la propria richiesta in sospeso e possono ruotare, revocare o rimuovere solo la propria voce dispositivo.

Approvazioni di pairing Node

Il vecchio node.pair.* usa un archivio di pairing dei nodi separato e di proprietà del Gateway. I nodi WS usano il pairing dei dispositivi con role: node, ma si applica lo stesso vocabolario a livello di approvazione.

node.pair.approve usa l'elenco dei comandi della richiesta in sospeso per derivare ulteriori ambiti richiesti:

Richiesta senza comandi: operator.pairing
Comandi del nodo non exec: operator.pairing + operator.write
system.run, system.run.prepare o system.which: operator.pairing + operator.admin

Il pairing dei nodi stabilisce identità e fiducia. Non sostituisce la policy di approvazione exec system.run propria del nodo.

Autenticazione con segreto condiviso

L'autenticazione con token/password Gateway condivisi è trattata come accesso operatore attendibile per quel Gateway. Le superfici HTTP compatibili con OpenAI, /tools/invoke e gli endpoint HTTP della cronologia sessione ripristinano il normale set completo predefinito di ambiti operatore per l'autenticazione bearer con segreto condiviso, anche se un chiamante invia ambiti dichiarati più ristretti.

Le modalità con identità, come l'autenticazione proxy attendibile o none per ingress privato, possono comunque rispettare ambiti dichiarati espliciti. Usa Gateway separati per una vera separazione dei confini di fiducia.

Was this useful?