Перейти до основного вмісту
Операторські області дії визначають, що клієнт Gateway може робити після автентифікації. Вони є запобіжником контрольної площини в межах одного довіреного домену оператора Gateway, а не ізоляцією від ворожих мультитенантних середовищ. Якщо вам потрібне надійне розділення між людьми, командами або машинами, запускайте окремі Gateways під окремими користувачами ОС або на окремих хостах. Пов’язано: Безпека, протокол Gateway, сполучення Gateway, CLI пристроїв.

Ролі

Клієнти Gateway WebSocket підключаються з однією роллю:
  • operator: клієнти контрольної площини, як-от CLI, Control UI, автоматизація та довірені допоміжні процеси.
  • node: хости можливостей, як-от macOS, iOS, Android або безголові вузли, які надають команди через node.invoke.
Методи Operator RPC потребують ролі operator. Методи, ініційовані вузлом, потребують ролі node.

Рівні областей дії

Область діїЗначення
operator.readСтатус лише для читання, списки, каталог, журнали, читання сеансів та інші виклики контрольної площини без змін.
operator.writeЗвичайні операторські дії зі змінами, як-от надсилання повідомлень, виклик інструментів, оновлення налаштувань talk/voice і ретрансляція команд вузла. Також задовольняє operator.read.
operator.adminАдміністративний доступ до контрольної площини. Задовольняє кожну область дії operator.*. Потрібен для зміни конфігурації, оновлень, нативних хуків, чутливих зарезервованих просторів імен і високоризикових затверджень.
operator.pairingКерування сполученням пристроїв і вузлів, зокрема перегляд списку, затвердження, відхилення, видалення, ротація та відкликання записів сполучення або токенів пристроїв.
operator.approvalsAPI затверджень exec і plugin.
operator.talk.secretsЧитання конфігурації Talk із включеними секретами.
Невідомі майбутні області дії operator.* потребують точного збігу, якщо викликач не має operator.admin.

Область дії методу — лише перший шлюз

Кожен Gateway RPC має область дії методу за принципом найменших привілеїв. Ця область дії методу визначає, чи може запит дійти до обробника. Деякі обробники потім застосовують суворіші перевірки під час затвердження на основі конкретного об’єкта, який затверджується або змінюється. Приклади:
  • 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-автентифікації зі спільним секретом, навіть якщо викликач надсилає вужчі оголошені області дії. Режими з ідентичністю, як-от автентифікація через довірений проксі або private-ingress none, усе ще можуть враховувати явно оголошені області дії. Використовуйте окремі Gateways для реального розділення меж довіри.