Области действия оператора

Области доступа оператора определяют, что клиент Gateway может делать после аутентификации. Это ограничитель плоскости управления внутри одного доверенного домена оператора Gateway, а не изоляция от недоверенных соседей в многопользовательской среде. Если вам нужно строгое разделение между людьми, командами или машинами, запускайте отдельные Gateway под отдельными пользователями ОС или на отдельных хостах. См. также: Безопасность, Протокол Gateway, Сопряжение Gateway, CLI устройств.

​

Роли

Клиенты Gateway WebSocket подключаются с одной ролью:

• operator: клиенты плоскости управления, такие как CLI, Control UI, автоматизация и доверенные вспомогательные процессы.
• node: хосты возможностей, такие как macOS, iOS, Android или узлы без графического интерфейса, которые предоставляют команды через node.invoke.

Методы RPC оператора требуют роль operator. Методы, инициированные узлом, требуют роль node.

​

Уровни областей доступа

Неизвестные будущие области доступа operator.* требуют точного совпадения, если у вызывающего клиента нет operator.admin.

​

Область доступа метода — только первый барьер

У каждого RPC Gateway есть область доступа метода по принципу минимальных привилегий. Эта область доступа метода определяет, может ли запрос попасть в обработчик. Затем некоторые обработчики применяют более строгие проверки во время подтверждения на основе конкретного объекта, который подтверждается или изменяется. Примеры:

• device.pair.approve доступен с operator.pairing, но при подтверждении операторского устройства можно выдать или сохранить только те области доступа, которые уже есть у вызывающего клиента.
• node.pair.approve доступен с operator.pairing, а затем выводит дополнительные области доступа подтверждения из ожидающего списка команд узла.
• chat.send обычно является методом с областью доступа на запись, но постоянные /config set и /config unset требуют operator.admin на уровне команды.

Это позволяет операторам с более низкими областями доступа выполнять низкорисковые действия сопряжения, не делая все подтверждения сопряжения доступными только администраторам.

​

Подтверждения сопряжения устройств

Записи сопряжения устройств являются долговечным источником подтвержденных ролей и областей доступа. Уже сопряженные устройства не получают более широкий доступ незаметно: повторные подключения, которые запрашивают более широкую роль или более широкие области доступа, создают новый ожидающий запрос на повышение доступа. При подтверждении запроса устройства:

• Запрос без роли оператора не требует подтверждения области доступа токена оператора.
• Запрос для неоператорской роли устройства, такой как node, требует operator.admin, даже когда device.pair.approve доступен с operator.pairing.
• Запрос на operator.read, operator.write, operator.approvals, operator.pairing или operator.talk.secrets требует, чтобы у вызывающего клиента были эти области доступа или operator.admin.
• Запрос на operator.admin требует operator.admin.
• Запрос восстановления без явно указанных областей доступа может унаследовать существующие области доступа токена оператора. Если существующий токен имеет область доступа администратора, подтверждение все равно требует operator.admin.

Неадминистративные сеансы с общим секретом и доверенным прокси могут подтверждать запросы операторских устройств только в пределах собственных объявленных областей доступа оператора. Подтверждение неоператорских ролей доступно только администраторам, даже когда такие сеансы в остальном могут использовать operator.pairing. Для сеансов токенов сопряженных устройств управление также ограничено самим устройством, если у вызывающего клиента нет operator.admin: вызывающие клиенты без прав администратора видят только собственные записи сопряжения, могут подтверждать или отклонять только собственный ожидающий запрос и могут ротировать, отзывать или удалять только собственную запись устройства.

​

Подтверждения сопряжения узлов

Устаревшие node.pair.* используют отдельное хранилище сопряжения узлов, принадлежащее Gateway. Узлы WS используют сопряжение устройств с role: node, но применяется тот же словарь уровней подтверждения. node.pair.approve использует список команд ожидающего запроса, чтобы вывести дополнительные требуемые области доступа:

• Запрос без команд: operator.pairing
• Не-exec команды узла: operator.pairing + operator.write
• system.run, system.run.prepare или system.which: operator.pairing + operator.admin

Сопряжение узлов устанавливает идентичность и доверие. Оно не заменяет собственную политику подтверждения exec для system.run узла.

​

Аутентификация с общим секретом

Аутентификация с общим токеном/паролем Gateway рассматривается как доверенный операторский доступ для этого Gateway. HTTP-поверхности, совместимые с OpenAI, /tools/invoke и HTTP-эндпоинты истории сеансов восстанавливают обычный полный набор областей доступа оператора по умолчанию для bearer-аутентификации с общим секретом, даже если вызывающий клиент отправляет более узкие объявленные области доступа. Режимы с идентичностью, такие как аутентификация через доверенный прокси или none для частного ingress, по-прежнему могут учитывать явно объявленные области доступа. Используйте отдельные Gateway для реального разделения границ доверия.