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.