Для операции создания робота в NKT автор описывает конкретное разделение ролей: ИИ-агент вызывает действие, а хаб помещает секрет в конвейер. В опубликованном 28 октября корпоративном материале «Автокода» на Habr говорится, что значение секрета агенту не передаётся. Для тех, кто рассматривает автоматизацию работы с внешними сервисами, здесь существенно различие между разрешением запустить операцию и получением данных, которые она использует.

Что вынесли в плагины

По описанию автора, ядро NKT содержит 29 действий развёртывания. Его задачи — развернуть сервис, проверить работоспособность и при необходимости перенести его. Связь хаба с внешними сервисами обеспечивают отдельные плагины: расширение возможностей описано через подключение таких служб, а не через увеличение числа действий самого ядра.

Каждый плагин представлен службой с именем вида nkt-plugin-<имя>. Автор указывает, что она работает без Docker и слушает только локальный адрес 127.0.0.1:9280. Это описание способа запуска и связи компонентов; само по себе оно ещё не отвечает на вопрос, кому разрешено вызывать конкретную операцию.

Возможности внешнего сервиса тоже имеют значение. В примере с плагином реестра rgstr разделы сканирования и резервного копирования скрываются, если реестр их не поддерживает. Поэтому наличие плагина не означает, что через него обязательно доступны все перечисленные функции: набор операций зависит и от версии подключённого реестра.

Кто разрешает запрос

Проверку доступа автор помещает на стороне хаба. До передачи запроса плагину хаб должен проверить права токена. В разделе об API указаны допуск к конкретному плагину и ограничения по объектам — хостам, проектам и конвейерам. Для ИИ-агентов через MCP отдельно оговорено: чтение доступно с любым токеном, а изменения в rgstr требуют допуска «плагин rgstr».

Для пользователя такой порядок означает, что чтение и изменение данных требуют разного доступа. При настройке изменений важно проверить два условия: есть ли допуск к нужному плагину и с какими объектами разрешено работать. Одного упоминания плагина недостаточно, чтобы понять весь объём полномочий: нужно учитывать и границы по объектам.

При этом заявленная проверка прав не равнозначна результату аудита безопасности. Материал объясняет предполагаемое поведение компонентов, но не доказывает, что его невозможно обойти. Рассматривать эту архитектуру как независимо проверенную защиту на основании одного описания было бы преждевременно.

Куда попадает секрет

Наиболее предметный пример в статье — операция rgstr_robot_create, то есть создание робота для конвейера. Автор утверждает, что агент вызывает её, после чего хаб помещает секрет непосредственно в конвейер. Значение секрета агенту при этом не выдаётся.

В пределах этого примера агенту достаточно возможности запросить действие: получать секрет и затем самостоятельно передавать его дальше ему не требуется. Это объясняет, зачем разделять участников операции. Компонент, который инициирует работу, и компонент, который помещает секрет в место использования, выполняют разные задачи.

Такое описание касается именно указанного механизма. Из него нельзя заключить, что ИИ-агент никогда не получает никаких секретов во всех остальных операциях NKT или что любые подключённые сервисы работают аналогично. Для оценки конкретного применения важно сохранить эту границу: пример создания робота не описывает автоматически весь продукт.

У операции есть и обязательное условие. По словам автора, без параметров to_pipeline и env она агенту недоступна. Параметр to_pipeline задаёт конвейер, а env — способ записи секрета: при значении @registry он попадает в раздел «Реестры» конвейера, при обычном имени переменной — в.env конвейера.

Источники и контекст

Сообщить об ошибке или уточнении