⚠️ ИИ в DevOps: слепое доверие сгенерированным манифестам

Kubernetes API server может молча принять сгенерированный ИИ манифест, отбросив устаревшие поля, — и Pod будет работать, пока не упадёт. Именно так случилось с Deployment для Go-сервиса: после apply всё выглядело Running, но liveness probe не срабатывал из-за изменения семантики полей между версиями кластера и теми, на которых обучалась модель. По данным Habr, это типичный сценарий: API server не ругается, логи чистые, а health check молча не работает.

Исследование 2026 года дало количественную картину: средний уровень уязвимостей в сгенерированном ИИ инфраструктурном коде — 57,5%, причём Dockerfile показал худший результат, близкий к провалу. Причина в смещении обучающих данных: модель училась на публичных репозиториях и руководствах, которые «запускаются на ноутбуке разработчика», а не на production-кластерах. Отсюда уверенно генерируемые `apiVersion: extensions/v1beta1`, удалённые ещё в Kubernetes 1.16 (2019 год), и несуществующие PodSecurityPolicy после версии 1.25.

Сгенерированный YAML почти всегда «выглядит правильно»: идеальный синтаксис, правильные отступы, комментарии. Это создаёт иллюзию компетентности. Но API server при встрече неизвестного поля либо отклоняет манифест (это нормально), либо молча отбрасывает его. Во втором случае вы получаете частично применённую конфигурацию: например, PodSecurityPolicy сгенерирован, валидатор не ругнулся, а фактически никаких ограничений нет. Контейнер по умолчанию работает от root, `allowPrivilegeEscalation: true`, `readOnlyRootFilesystem: false` — и это прямой путь к побегу на хост.

Отказываться от ИИ в DevOps не обязательно, но нужен слой валидации, как для любого внешнего кода. Минимум три проверки: `kubeconform -strict` под точную версию кластера (ловит устаревшие имена полей), `conftest` с Rego-политиками (запрет `:latest`, требование `runAsNonRoot` и лимитов), и `kubectl apply --dry-run=server` — он прогоняет манифест через admission webhooks без персистенции. Эти шаги не гарантируют безопасность, но закрывают разрыв между «сгенерировано» и «развёрнуто».

Проблема не в том, что LLM ошибается, а в том, что обучающие данные изначально не содержат production-паттернов. Улучшать модель бесполезно — она не знает вашу версию кластера и ваши CRD. Инженерное решение — это не доверие к ИИ, а конвейер валидации, который мы и так строим для любого внешнего кода. Если вы генерируете манифест и сразу пушите в прод без этих трёх шагов, вы доверяете не ИИ, а удаче.

#Kubernetes #DevOps #LLM #Security