Ámbitos del operador

Los ámbitos de operador determinan lo que un cliente del Gateway puede hacer después de autenticarse. Son una medida de protección del plano de control dentro de un único dominio de operadores de confianza del Gateway, no un aislamiento multiinquilino frente a actores hostiles. Para establecer una separación sólida entre personas, equipos o máquinas, ejecute Gateways independientes con usuarios del sistema operativo o hosts distintos.

Relacionado: Seguridad, Protocolo del Gateway, Emparejamiento del Gateway, CLI de dispositivos.

Roles

Cada cliente WebSocket del Gateway se conecta con un rol:

• operator: clientes del plano de control, como la CLI, la interfaz de control, la automatización y los procesos auxiliares de confianza.
• node: hosts de capacidades (macOS, iOS, Android, sin interfaz gráfica) que exponen comandos mediante node.invoke.

Los métodos RPC de operador requieren el rol operator; los métodos originados por nodos requieren el rol node.

Niveles de ámbito

Los ámbitos operator.* futuros y desconocidos requieren una coincidencia exacta, salvo que el autor de la llamada ya disponga de operator.admin.

El ámbito del método es solo la primera barrera

Cada RPC del Gateway tiene un ámbito de método de privilegios mínimos que determina si una solicitud llega a su controlador. Algunos controladores aplican después comprobaciones más estrictas según el elemento concreto que se apruebe o modifique:

• device.pair.approve es accesible con operator.pairing, pero la aprobación de un dispositivo de operador solo puede emitir o conservar ámbitos que el autor de la llamada ya posea.
• node.pair.approve es accesible con operator.pairing y después deriva ámbitos de aprobación adicionales de la lista de comandos declarada por el nodo pendiente.
• chat.send es un método con ámbito de escritura, pero los comandos de chat /config set y /config unset requieren además operator.admin, independientemente del ámbito de envío de chat del autor de la llamada.

Esto permite que los operadores con ámbitos inferiores realicen acciones de emparejamiento de bajo riesgo sin exigir acceso administrativo para todas las aprobaciones de emparejamiento.

Aprobaciones de emparejamiento de dispositivos

Los registros de emparejamiento de dispositivos son la fuente persistente de los roles y ámbitos aprobados. Un dispositivo ya emparejado no obtiene silenciosamente un acceso más amplio: una reconexión que solicite un rol o ámbitos más amplios crea una nueva solicitud de ampliación pendiente.

Al aprobar una solicitud de dispositivo:

• Una solicitud sin rol de operador no necesita aprobación de ámbitos de operador.
• Una solicitud para un rol de dispositivo que no sea de operador (por ejemplo, node) requiere operator.admin, aunque device.pair.approve solo necesite operator.pairing.
• Una solicitud de operator.read, operator.write, operator.approvals, operator.pairing o operator.talk.secrets requiere que el autor de la llamada ya disponga de ese ámbito o de operator.admin.
• Una solicitud de operator.admin requiere operator.admin.
• Una solicitud de reparación sin ámbitos explícitos puede heredar los ámbitos del token de operador existente; si ese token tiene ámbito administrativo, la aprobación sigue requiriendo operator.admin.

Las sesiones no administrativas con secreto compartido o proxy de confianza solo pueden aprobar solicitudes de dispositivos de operador dentro de sus propios ámbitos de operador declarados; la aprobación de roles que no sean de operador requiere acceso administrativo, aunque esas sesiones puedan utilizar operator.pairing de otro modo.

En las sesiones con token de dispositivo emparejado, la gestión se limita al propio dispositivo, salvo que el autor de la llamada disponga de operator.admin: un autor de llamadas no administrativo solo ve sus propias entradas de emparejamiento y solo puede aprobar, rechazar, rotar, revocar o eliminar la entrada de su propio dispositivo.

Aprobaciones de emparejamiento de nodos

Los métodos heredados node.pair.* utilizan un almacén independiente de emparejamiento de nodos gestionado por el Gateway. Los nodos WS utilizan en su lugar el emparejamiento de dispositivos (role: node), pero se aplica el mismo vocabulario de aprobación. Consulte Emparejamiento del Gateway para conocer la relación entre ambos almacenes.

node.pair.approve deriva ámbitos obligatorios adicionales de la lista de comandos de la solicitud pendiente:

Aprobar una declaración de nodo no habilita los comandos que tienen una barrera independiente de lista de permitidos en tiempo de ejecución. Por ejemplo, aprobar un nodo que declara computer.act requiere emparejamiento y ámbito de escritura, pero solo registra la superficie. Un administrador o propietario aún debe habilitar computer.act. Mientras permanezca habilitado, invocarlo mediante el método con ámbito de escritura node.invoke no requiere ámbito administrativo para cada acción.

El emparejamiento de nodos establece la identidad y la confianza; no sustituye la propia política de aprobación de ejecución system.run de un nodo.

Autenticación con secreto compartido

La autenticación mediante token o contraseña compartidos del Gateway se considera acceso de operador de confianza para ese Gateway. Las superficies HTTP compatibles con OpenAI, /tools/invoke y los endpoints HTTP del historial de sesiones restauran el conjunto completo de ámbitos de operador predeterminado para la autenticación de portador con secreto compartido, aunque el autor de la llamada envíe ámbitos declarados más restringidos.

Los modos que incorporan identidad, como la autenticación mediante proxy de confianza o none de entrada privada, pueden seguir respetando los ámbitos declarados explícitamente. Utilice Gateways independientes para separar verdaderos límites de confianza.