ИИ-модели часто генерируют манифесты Kubernetes на основе публичных данных, которые не соответствуют стандартам безопасности для продакшена. Исследование 2026 года показало, что уровень уязвимостей в сгенерированном инфраструктурном коде достигает 57,5%, при этом Dockerfile демонстрируют худшие показатели среди всех типов артефактов.
Нейросети нередко используют устаревшие версии API, например 'extensions/v1beta1' для Deployment или 'networking.k8s.io/v1beta1' для Ingress, удаленные еще в Kubernetes 1.16. Также ИИ часто игнорирует настройку 'securityContext', из-за чего контейнеры запускаются с правами root, что создает критические риски безопасности при эксплуатации в реальной среде.
Проблема усугубляется тем, что API-сервер Kubernetes может молча игнорировать некорректные или устаревшие поля. В результате манифест принимается кластером, но часть настроек не применяется. Например, из-за семантических ошибок в манифесте может не сработать Liveness probe, и под останется в статусе 'Running', несмотря на фактическую неработоспособность сервиса.
Для минимизации рисков эксперты рекомендуют использовать 'kubeconform' с флагом '-strict' для проверки манифестов под конкретную версию кластера. Также необходимо применять 'conftest' с Rego-политиками для контроля безопасности, например, проверки 'runAsNonRoot'. Финальной проверкой перед деплоем должна стать команда 'kubectl apply --dry-run=server', позволяющая убедиться в корректной обработке ресурса API-сервером.
