С одной стороны, все исполнение можно вынести в пайплайн, с другой, если можем защититься от нежелательных действий на раннере, то что нам мешает это сделать в среде агента.
Все верно, из коробки поддерживается MITM-инъекция для ограниченного набора сервисов, однако, рабочий MITM прокси, который будет поддерживать абсолютно все сервисы, это прям большая головная боль. Как обсуждали ниже, частично это решается выдачей прав агенту с ограниченным доступом.
Задумался о технической реализации этого. Предполагаем что агентам не верим и что просто промпта нам недостаточно. Хуки? Отобрать у пользователя, запускающего агента, права на запись в директорию?
А вот удобство работы в отдельной VM всегда будет сильно хуже, чем в привычной среде на хосте - и моё решение умудряется совместить безопасность и это удобство, чем и уникально
Насчет совмещения плюсов во многом соглашусь. За исключением отсутствия отдельного ядра внутри.
У меня там два варианта. На базе Linux namespaces синхронизация обеспечивается через ro bind-mount этих конфигов, что моментально.
Расскажите, пожалуйста, подробнее или укажите место в репозитории, где посмотреть. Видимо, не все верно понял, но пока кажется, что и скрытые от гита файлы, которые обсуждали парой сообщений выше, должны синхронизироваться.
На мой взгляд категорически неприемлемо шарить каталог проекта с агентом. Агент должен работать как отдельный сотрудник, с собственным клоном репо проекта, в собственном домашнем каталоге, имея доступ только к разрешённым для него секретам.
Разделяю этот подход, хоть у нас и немного разошлись взгляды на шеринг рабочих директорий.
Сильно за рассматривать агента как отдельного актора, что подразумевает, в том числе, выдачу ему персонализированных учетных данных.
У меня там два варианта. На базе Linux namespaces синхронизация обеспечивается через ro bind-mount этих конфигов, что моментально. На базе ssh на localhost синхронизация пока сделана через rsync при запуске, в целом работает прекрасно, но есть и другие варианты на будущее. Но синхронизация конфигов это половина дела, ещё нужно открывать ссылки в браузере хоста, сохранять look&feel DE хоста для GUI приложений, показывать десктопные уведомления на хосте, проигрывать звуковые уведомления, etc. В целом у меня всё получилось - работа в песочнице никак не ощущается отличной от работы на хосте в плане UX.
Очевидное пустое поле для sbx это агентные IDE, в том числе Cursor. Нет из коробки варианта запуска Cursor IDE в песочнице так, чтобы агент шарил ручками в песочнице, а GUI был доступен пользователю через хост без задержек. Смотрели ли в эту сторону?
Ps насчет Readme пока не успеваю ознакомиться, вернусь позже
Для ускорения да, это неочевидный плюс изоляции, но это действительно так, когда понятен потенциальный убыток, легко отпустить агент в свободное плавание. Нередко запускаю несколько агентов параллельно для разных проектов.
Приятно видеть комментарий, реализующий альтернативный подход.
Насчет малозаметных файлов тейк понятный, сам об этом думал, но решил, что граница между безопасностью и комфортом для меня пролегает в первую очередь по непреднамеренным деструктивным действиям агента. Меня в первую очередь пугает неожиданное изменение системных файлов или пресловутый rm rf, а sandbox для этого подходит идеально.
Кстати, замечательная идея насчет клона репо, пока писал статью, завезли новое, что в обзор не попало. Dokcer sbx стал из коробки поддерживать Clone mode, насколько это близко вашему подходу и реализации?
Что касается настроенной IDE хоста, улавливаю некое противоречие, наличие отдельной копии для агента неизбежно ухудшает скорость синхронизации, в случае с подключение по SSH к среде разработки в локальной песочнице да, этот момент решается, хоть и сложнее настраивать окружение.
А вот насчет шарить окружение категорически не согласен, все переменные окружение, доступные агенту, потенциально под угрозой.
Расскажите, а как у вас дела с Docker контейнерами? Доступно ли внутри песочницы изолированное ядро для запуска контейнеров?
Для меня отлично подошел вариант с изоляцией через sbx, в частности, ключи можно держать снаружи песочницы за счет sbx secret и агент не будет видеть никакие секреты
Вы отлично описали два полярных подхода, но полноценные виртуальные машины для меня заметно снижали комфорт использования, в статье как раз описан промежуточный вариант, удобно как в докере, надежно, как в виртуалке.
Напишите по этой теме на Хабр! Интересно почитать.
Так получилось, что у меня как раз VMware гипервизор, до использования Docker sbx, он запускается на нативной виртуализации ОС, Hyper v для Windows.
А можете поделиться процессом, сколько нужно параллельных ВМ и сколько памяти в каждой, чтобы было комфортно?
Здорово, пока не дошел посмотреть репозиторий, но очень интересно. А есть опции насчет запуска Cursor?
С одной стороны, все исполнение можно вынести в пайплайн, с другой, если можем защититься от нежелательных действий на раннере, то что нам мешает это сделать в среде агента.
А можете, пожалуйста, поделиться кейсами, что за тяжелое окружение? Возможно, всем вместе интересно будет подумать над решением
Вы описали сейчас Docker sbx по функционалу и это звучит здорово. Круто, что опенсорс;
А есть возможность настроить не системный, а просто прокси снаружи VM? Например, через локальный докер контейнер
И аналогичный вопрос, как и комментатору выше, что насчет Cursor с интерфейсом?
Пока вы рассказываете довольно интересно, посмотрю, и, если интересен отзыв, вернусь в течение пару недель
Все верно, из коробки поддерживается MITM-инъекция для ограниченного набора сервисов, однако, рабочий MITM прокси, который будет поддерживать абсолютно все сервисы, это прям большая головная боль. Как обсуждали ниже, частично это решается выдачей прав агенту с ограниченным доступом.
Задумался о технической реализации этого. Предполагаем что агентам не верим и что просто промпта нам недостаточно. Хуки? Отобрать у пользователя, запускающего агента, права на запись в директорию?
Еще отдельная боль для меня была монтирование директорий, не все всегда все видит
Хорошая мысль, включу это в следующую часть статьи, а что для вас "тяжелая сборка"?
Насчет совмещения плюсов во многом соглашусь. За исключением отсутствия отдельного ядра внутри.
Расскажите, пожалуйста, подробнее или укажите место в репозитории, где посмотреть. Видимо, не все верно понял, но пока кажется, что и скрытые от гита файлы, которые обсуждали парой сообщений выше, должны синхронизироваться.
Разделяю этот подход, хоть у нас и немного разошлись взгляды на шеринг рабочих директорий.
Сильно за рассматривать агента как отдельного актора, что подразумевает, в том числе, выдачу ему персонализированных учетных данных.
Очевидное пустое поле для sbx это агентные IDE, в том числе Cursor. Нет из коробки варианта запуска Cursor IDE в песочнице так, чтобы агент шарил ручками в песочнице, а GUI был доступен пользователю через хост без задержек. Смотрели ли в эту сторону?
Ps насчет Readme пока не успеваю ознакомиться, вернусь позже
Для ускорения да, это неочевидный плюс изоляции, но это действительно так, когда понятен потенциальный убыток, легко отпустить агент в свободное плавание. Нередко запускаю несколько агентов параллельно для разных проектов.
Приятно видеть комментарий, реализующий альтернативный подход.
Насчет малозаметных файлов тейк понятный, сам об этом думал, но решил, что граница между безопасностью и комфортом для меня пролегает в первую очередь по непреднамеренным деструктивным действиям агента. Меня в первую очередь пугает неожиданное изменение системных файлов или пресловутый rm rf, а sandbox для этого подходит идеально.
Кстати, замечательная идея насчет клона репо, пока писал статью, завезли новое, что в обзор не попало. Dokcer sbx стал из коробки поддерживать Clone mode, насколько это близко вашему подходу и реализации?
Что касается настроенной IDE хоста, улавливаю некое противоречие, наличие отдельной копии для агента неизбежно ухудшает скорость синхронизации, в случае с подключение по SSH к среде разработки в локальной песочнице да, этот момент решается, хоть и сложнее настраивать окружение.
А вот насчет шарить окружение категорически не согласен, все переменные окружение, доступные агенту, потенциально под угрозой.
Расскажите, а как у вас дела с Docker контейнерами? Доступно ли внутри песочницы изолированное ядро для запуска контейнеров?
Вы имеете в виду выстраивание изоляции и инъекции секретов своими руками?
Все так и докер прямо указывает это в документации. sbx secret позволяет хранить набор ключей для ограниченного числа поддерживаемых сервисов
Upd
"никакие" звучит слишком радикально, стоило сформулировать мягче, "не будет видеть секреты, добавленные в sbx secret"
Для меня отлично подошел вариант с изоляцией через sbx, в частности, ключи можно держать снаружи песочницы за счет sbx secret и агент не будет видеть никакие секреты
Вы отлично описали два полярных подхода, но полноценные виртуальные машины для меня заметно снижали комфорт использования, в статье как раз описан промежуточный вариант, удобно как в докере, надежно, как в виртуалке.
С ростом и стремительным изменением ландшафта специфичных угроз согласен, сюда напрашивается строгая RBAC модель