Gateway

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

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

См. также: Безопасность, Протокол Gateway, Сопряжение Gateway, CLI устройств.

Роли

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

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

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

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

Область Значение
operator.read Состояние только для чтения, списки, каталог, журналы, чтение сеансов и другие вызовы, не изменяющие данные.
operator.write Изменяющие действия оператора: отправка сообщений, вызов инструментов, обновление настроек разговора и голоса, ретрансляция команд Node. Также включает operator.read.
operator.admin Административный доступ. Включает все области operator.*. Требуется для изменения конфигурации, обновлений, нативных хуков, зарезервированных пространств имён и подтверждений операций высокого риска.
operator.pairing Управление сопряжением устройств и Node: просмотр списка, одобрение, отклонение, удаление, ротация, отзыв.
operator.approvals API подтверждения выполнения и плагинов.
operator.talk.secrets Чтение конфигурации Talk, включая секреты.

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

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

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

  • device.pair.approve доступен с operator.pairing, но при одобрении устройства оператора можно создать или сохранить только те области, которыми уже обладает вызывающая сторона.
  • node.pair.approve доступен с operator.pairing, после чего определяет дополнительные области одобрения из заявленного списка команд ожидающего Node.
  • 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

Устаревшие методы node.pair.* используют отдельное хранилище сопряжений Node, принадлежащее Gateway. Вместо этого Node, использующие WS, применяют сопряжение устройств (role: node), но используется та же терминология одобрения. О связи этих двух хранилищ см. в разделе Сопряжение Gateway.

node.pair.approve определяет дополнительные обязательные области из списка команд ожидающего запроса:

Заявленные команды Обязательные области
нет operator.pairing
команды Node, не связанные с выполнением operator.pairing + operator.write
system.run, system.run.prepare или system.which operator.pairing + operator.admin

Одобрение декларации Node не включает команды, для которых действует отдельный список разрешений времени выполнения. Например, одобрение Node, заявляющего computer.act, требует области сопряжения и записи, но лишь регистрирует доступную поверхность. Администратор или владелец всё равно должен включить computer.act. Пока он остаётся включённым, его вызов через метод node.invoke с областью записи не требует административной области для каждого действия.

Сопряжение Node устанавливает идентичность и доверие; оно не заменяет собственную политику одобрения выполнения system.run этого Node.

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

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

Режимы с идентификацией, такие как аутентификация через доверенный прокси или none с приватным входящим доступом, по-прежнему могут учитывать явно заявленные области. Для реального разделения границ доверия используйте отдельные Gateway.

Was this useful?
On this page

On this page