Типовая история: платформенная команда выдаёт агенту kubeconfig прода, чтобы он сам диагностировал инциденты и катал деплои. Работает — до первого инцидента безопасности: агент читает секреты из логов, выполняет деструктивную команду по инструкции из тикета и оставляет после себя ноль аудита. В обсуждениях SRE-команд 2026 года это уже не кейс, а мейнстрим-вопрос: «вы даёте агентам доступ к продакшену?» — и большинство ответов описывают полный kubeconfig как норму. Разберём, как дать агенту нужные действия, не выдавая ключи от прод-кластера.
Почему read-only роль не спасает
Первая реакция — «дадим роль с read-only». Это лучше, чем ничего, но не решает проблему: read-only открывает чтение секретов и логов — самый ценный путь утечки; а если разрешения на изменения всё же выданы, любой гейт «по имени команды» падает под промпт-инъекцией — атакующий не ломает политику, а просит агента выполнить легитимную команду с неверной целью. Вопрос инфраструктурного доступа — не «какой роли выдать», а как устроен путь от решения агента до исполнения.
Четыре слоя инфраструктурного доступа
- Что разрешено. Allowlist команд и операций: диагностика и чтение статусов — по умолчанию; изменения — только конкретные типы (scale, deploy, restart), не абстрактный kubectl.
- К чему применено. Scope по namespace и лейблам: агентProd видит только свои приложения; чтение секретов — запрещено на уровне RBAC, а не обещанием.
- Что видно из ответа. Ответ инструмента проходит санитайзинг: маскирование токенов, обрезка логов с персональными данными — чтобы прод не утёк в контекст модели и не вернулся в интерфейс.
- Как это записано. Каждый вызов — аудируемая операция: кто, когда, какая команда, с какими параметрами, кто одобрил.
Изоляция исполнения: Agent Sandbox
Весной 2026 года Kubernetes принял Agent Sandbox — проект для запуска агентов в изолированной среде внутри кластера. Sandbox CRD даёт stateful singleton-workload с собственной сетевой и kernel-изоляцией (gVisor/Kata), стабильной идентичностью и scale-to-zero, а SandboxWarmPool убирает холодный старт. Практический смысл: агент, которому нужна инфраструктура, работает в объявленном периметре, а не на вашем ноутбуке или CI-раннере с валидным вечным токеном.
Одобрения и JIT-доступ
Изменения в проде идут через два барьера. Первый — approval: изменение, которое агент собрался сделать, показывается человеку в виде диффа, человек одобряет или отклоняет. Второй — JIT: даже одобренное право выдаётся на короткое время и автоматически отзывается. Постоянный широкий доступ агенту не нужен почти никогда: 90% его работы — диагностика, которую полностью закрывает ограниченный read-only с санитайзингом ответов.
Kill switch и проверки
Подготовьте два сценария заранее. Отзыв: одна операция отзывает у агента все права в кластере — включая те, что выданы через RBAC, брокер и прямые токены. Проверка: периодический тест «что агент может сделать сейчас» — список эффективных прав по каждому агенту, сверка с заявленным. Если фактические права шире заявленных — это инцидент, даже если агент пока ничего плохого не сделал.
Где Codenik
Codenik даёт агенту инструменты вместо kubeconfig: агент вызывает инструмент «прочитать статус», «посмотреть логи», «применить изменение» — а не сырой kubectl. На стороне Codenik — scope по namespace, запрет чтения секретов, санитайзинг ответов, гейт одобрения для изменений и полный журнал команд с параметрами. Отзыв — одна операция. Инфраструктура остаётся за брокером, агент получает ровно те действия, которые разрешены его ролью.
Короткий вывод
Инфраструктурный доступ агента — архитектурное решение, а не флаг прав: allowlist действий, scope по объектам, санитайзинг ответов, аудит каждого вызова, изоляция исполнения, одобрение изменений и JIT вместо постоянных прав. Kubeconfig агента не выдавать — выдавать инструменты.