Дать ИИ-помощнику доступ к Proxmox: где должна проходить граница
Работа, которую модель делает действительно хорошо, читать длинные журналы и находить место поломки, это ровно та работа, которую ей обычно не дают делать. Причина: сегодняшние способы вручают ей root, а риск не в злом умысле, а в нехватке контекста.
AtlasPVE ·
Эта статья отвечает на
- proxmox mcp server
- может ли ии управлять proxmox
- доступ ии к proxmox безопасность
- риск дать llm доступ к серверу
- best proxmox mcp server
Здесь есть настоящий и слегка досадный перекос. Прочитать две тысячи строк журнала и найти строку, где что-то сломалось, это ровно то, что языковая модель умеет хорошо. И это же ровно та работа, которую большинство не может ей доверить, из-за того, как выдаётся доступ.
Вопрос не в том, должна ли модель трогать сервер. Вопрос в том, где проходит граница, и сегодня она обычно проходит не там.
Почему привычная схема неуютна
Есть два обычных способа подключить помощника к Proxmox: дать SSH-сессию или полноправный токен API. Оба сводятся к одному. С этого момента между моделью и железом не стоит ничего, а вся защита живёт в формулировке инструкции.
Инструкция это не граница. Это просьба к системе, созданной быть полезной, на языке без принудительной силы.
Риск в нехватке контекста, а не в злом умысле
Именно здесь диагноз ставят неверно. Форма отказа редко бывает «модель решила навредить». Обычно модель действует правильно на неполной картине.
Диск, который выглядит пустым. Модель читает устройство без смонтированной файловой системы и считает его свободным. Устройство принадлежит машине, которая просто выключена.
Деградировавший пул. Модель читает деградировавшее состояние и предлагает пересобрать массив. Правильным шагом была замена одного диска, а пересборка это способ потерять оставшиеся данные.
Служба, которая «не работает». Она не работает, потому что запускается по расписанию и уже отработала. Перезапустить безобидно; отключить, потому что она «постоянно падает», нет.
Во всех трёх команда написана верно. Неверна посылка, а верная команда на неверной посылке задним числом неотличима от саботажа.
Только чтение помогает и не является полным ответом
Очевидный ответ это доступ только на чтение, и он действительно убирает худшие исходы. Остаются две вещи.
Чтение не бесплатно. Конфигурация, журналы и записи аудита содержат имена узлов, адреса, имена пользователей и иногда токены, вставленные туда, куда не следовало. Помощник с полным охватом чтения это экспорт вашей инфраструктуры.
Диагностика без действия останавливается на полпути. Если полезный ответ это «перезапусти вот эту одну службу», схема с чтением возвращает находку человеку, чтобы он её перенабрал. Это нормально, и это же причина, по которой права позже тихо расширяют.
Значит, только чтение это хорошее начало и плохая конечная точка. Конечная точка это узкий доступ на запись через те же ворота, что проходит человек.
Где граница на самом деле должна быть
Не в инструкции и не внутри модели. В слое, который исполняет, потому что это единственное место, способное отказать.
Три свойства делают такой слой заслуживающим доверия, и все три проверяемы, а не обещаны.
Права приходят из системы, у которой они уже есть. Если помощник подключается существующей учётной записью, то что позволено этой записи, ровно то позволено и помощнику. Вторая модель прав не изобретается, значит нечего держать в синхронизации и нет способа этим двум противоречить друг другу.
Разрушительные операции проходят те же ворота, что и человек. Если удаление диска спрашивает человека о подтверждении, оно должно спрашивать и когда просит модель. Путь, безопасный для людей и открытый для автоматики, это не граница, а короткая дорога с красивым названием.
Каждый шаг попадает в журнал аудита. Кто, что, когда, над чем и с каким результатом. Без этого настоящий вопрос после инцидента, «это сделал помощник», остаётся без ответа, а отсутствие ответа само по себе повод не давать доступ.
Вопрос, который стоит задать о любом таком инструменте
Не «безопасно ли это», а «что именно отказывает и где оно живёт?»
Если ответ «модели сказали так не делать», границы нет. Если ответ «исполняющий слой проверяет права учётной записи и пропускает разрушительные шаги через ворота», граница есть, и её можно проверить: подключитесь ограниченной записью и убедитесь, что отказ настоящий.
Что делает Atlas
⚠️ Этот слой запланирован, а не выпущен. Дальше идёт замысел, по которому он строится; он записан здесь потому, что вопрос выше заслуживает честного ответа, а не рекламного.
Замысел в том, чтобы помощник подключался к Atlas, а не к Proxmox. Proxmox лежит ниже, и модель никогда не достаёт до него напрямую; она может использовать только то, что умеет сам Atlas, а значит все существующие ворота остаются на пути.
Границу проводят права Proxmox, то есть первое свойство выше: к чему может прикасаться подключённая учётная запись, к тому и прикасается помощник, и нового понятия прав не появляется. Разрушительные операции сохраняют уже имеющееся подтверждение, а журнал аудита уже записывает кто, что, когда, над чем и с каким результатом для каждого привилегированного действия, включая отклонённые.
Он также задуман как отдельный компонент, а не часть установки: на машине, которая его не хочет, его никогда нет. Это важно по той же причине, что и весь остальной текст. Самая надёжная граница для возможности, которую вы не выбирали, это её отсутствие.
Источники
Собственная документация Proxmox. На английском, и последнее слово в этом вопросе за ней.