Google Cloud представив керований сервіс GKE Agent Sandbox, тоді як проєкт із відкритим кодом kubernetes-sigs/agent-sandbox надає таку ж можливість будь-якому кластеру Kubernetes. Обидва варіанти надають розробникам тимчасовий Linux-контейнер для ШІ-агентів, не зачіпаючи решту інфраструктури.
Чому коду, згенерованому ШІ, потрібен безпечний майданчик
Сучасні ШІ-агенти не просто відповідають на запитання. Вони пишуть скрипти, переглядають вебсторінки, виконують команди оболонки (shell) і навіть запускають вебсервіси. Така потужність створює прогалину в безпеці: код, який вони видають, може бути з помилками, шкідливим або надто агресивним. Агент, який виконує rm -rf / або підключається до внутрішньої бази даних без дозволу, може скомпрометувати всю систему.
Пісочниця (sandbox) ізолює кожного агента в його власному контейнері — крихітній тимчасовій віртуальній машині. Якщо агент поводиться неналежним чином, шкода залишається всередині цього контейнера; хост і інші робочі навантаження залишаються в безпеці. Нова пропозиція GKE та проєкт, керований спільнотою, перетворюють цю ідею на готовий до використання сервіс.
Два способи отримати пісочницю
- GKE Agent Sandbox — повністю керований сервіс для клієнтів Google Cloud.
kubernetes-sigs/agent-sandbox— проєкт із відкритим кодом для будь-якого кластера Kubernetes.
Обидва варіанти мають однакову базову архітектуру, побудовану на стандартних примітивах Kubernetes.
Як влаштована система
| Компонент | Роль |
|---|---|
| Sandbox | Ізольований контейнер, у якому виконується код агента. Він має стабільне ім'я та, за потреби, постійне сховище. |
| SandboxTemplate | Шаблон, який визначає образ контейнера та політики безпеки — «рецепт» для створення нових пісочниць. |
| SandboxClaim | Запит, надісланий агентом (або його контролером) для запуску пісочниці за певним шаблоном. |
| SandboxWarmPool | Пул попередньо створених пісочниць, готових до миттєвого надання. Підтримка контейнерів у «теплому» стані дозволяє уникнути затримок, пов'язаних із завантаженням образів та запуском нового пода щоразу. |
Коли агенту потрібне середовище, він надсилає SandboxClaim. Контролер перевіряє теплий пул, вибирає вільну пісочницю та прив'язує її до запиту. Якщо пул порожній, він створює нову пісочницю за шаблоном; в іншому випадку передача відбувається за мілісекунди.
Налаштування безпеки, які ви можете змінити
- Default-deny networking (мережевий доступ за замовчуванням заборонено) — За замовчуванням пісочниця не має доступу до внутрішньої мережі. Ви повинні додати явні правила для дозволу вихідних або вхідних з'єднань, що запобігає випадковому розкриттю внутрішніх сервісів.
- Рівні ізоляції — Виберіть середовище виконання контейнерів (container runtime), яке відповідає вашому рівню допустимого ризику:
- Стандартні контейнери для швидкості,
- gVisor для додаткового рівня ізоляції в просторі користувача, або
- Kata Containers для апаратної ізоляції, що працює як легка віртуальна машина.
- SDK — Клієнтські бібліотеки для Python та Go дозволяють розробникам програмно створювати, запитувати та видаляти пісочниці, що ідеально вписується в робочий процес конвеєрів (pipelines) на базі ШІ.
Кому це вигідно, а хто може виступити проти
Підсумок
Надання ШІ-агентам власного тимчасового Linux-середовища усуває найбільшу невизначеність в автоматизації на базі ШІ: ризик того, що згенерований код зруйнує хост. Керований сервіс GKE Agent Sandbox від Google Cloud та проєкт kubernetes-sigs/agent-sandbox, що підтримується спільнотою, роблять таку ізоляцію практичною як для хмарних (cloud-native), так і для локальних (on-prem) середовищ. Організації, яким потрібно балансувати між гнучкістю та безпекою, тепер мають конкретний, нативний для Kubernetes інструмент, щоб тримати згенерований ШІ код у безпечній «пісочниці».