NeuVector — это открытая платформа для обеспечения безопасности контейнеров и кластеров Kubernetes. Она разрабатывалась как комплексное решение IDS/IPS и сейчас входит в портфель компании SUSE.
Недавно мы по запросу сообщества реализовали интеграцию NeuVector в виде модуля для Deckhouse Kubernetes Platform. Однако наш опыт показывает, что NeuVector не является надёжным инструментом обеспечения безопасности для production-сред. Ниже представлены аргументы, подтверждающие нашу позицию, несмотря на отдельные сценарии, где использование данного решения может быть оправдано.
Возможные сценарии применения NeuVector
Важно: мы НЕ рекомендуем использовать NeuVector в production-средах, за исключением случаев, когда у компании отсутствуют компетенции в части кибербезопасности либо требуется «лёгкий старт» с минимальными трудозатратами.
Тем не менее стоит отметить, что решение может быть полезно в ряде специфических ситуаций.
1. Быстрая организация базовой безопасности Kubernetes
NeuVector предоставляет функциональность IDS/IPS «из коробки», позволяя относительно быстро развернуть решение для инспекции и контроля сетевого трафика и системных вызовов приложений. Это уместно для компаний, у которых нет выделенного отдела информационной безопасности, поскольку снимает часть сложности первичной настройки.
2. Интеграция в enterprise-сегменте с регуляторными требованиями
Инструмент иногда используют крупные компании, которым нужно реализовать требования стандартов комплаенса, например GDPR. NeuVector позволяет сегментировать сетевые потоки, реализовать инспекцию внутри кластера и формировать отчётность для аудита.
Следует учитывать, что отчётность и поддержка в первую очередь ориентированы на западный enterprise. Например, NeuVector не поддерживает самоподписанные CA-сертификаты, которые широко используются в российском корпоративном секторе.
3. Визуализация и ручное управление сетевым взаимодействием
NeuVector предоставляет неплохой, хотя и весьма устаревший графический интерфейс для визуализации сетевых связей между сервисами и выявления уязвимостей на уровне соединений и портов. Он может быть удобен для инфраструктурных администраторов, не обладающих экспертизой в Kubernetes и других Cloud Native-инструментах.
4. Работа с устаревшими (legacy) и смешанными инфраструктурами
NeuVector продолжает работать в старых версиях Kubernetes и с проектами на Docker/Swarm — там, где современные инструменты (Falco, Trivy и другие) могут работать, но требуют более сложной настройки для этих сред исполнения, тогда как у NeuVector поддержка «из коробки».
5. Минимизация усилий на ручную настройку
Функция self-learning позволяет за короткое время получить базовый уровень защиты без глубокого изучения бизнес-логики приложения. Такой путь подходит для небольших организаций и относительно статичных рабочих нагрузок.
Подытожим
В каких случаях NeuVector — это осознанный выбор:
Когда приоритет — максимально быстро интегрируемая система безопасности сети на базе IDS/IPS в кластере без необходимости самостоятельного написания низкоуровневых политик.
Когда важны отчётность и визуализация сетевой картины (так, как её представляют разработчики NeuVector) — для обучения персонала, аудита или анализа post mortem.
Когда инфраструктура устаревшая или смешанная и нет ресурса на её полную перестройку и внедрение более современных, интегрируемых инструментов.
Когда бизнес ставит во главу угла соответствие стандартам комплаенса (GDPR), где требуется поддерживать внутреннюю сегментацию и аудируемость трафика.
Когда команда не хочет или не может писать кастомные политики безопасности runtime (как в Falco или Open Policy Agent), а желает автоматизации с минимумом ручного труда.
Почему мы не рекомендуем использовать NeuVector в production
Несмотря на ряд преимуществ, у NeuVector есть существенные ограничения и недостатки.
1. Архитектурные ограничения
Основа архитектуры проекта была заложена до массового распространения контейнеров — в 2016 году. Из-за этого в платформе используются устаревшие подходы, например запуск нескольких сервисов внутри одного контейнера через супервизор. Это затрудняет обновление компонентов и диагностику сбоев. Sidecar-контейнеры намного прозрачнее в эксплуатации.
Архитектура проекта в целом очень хрупкая. Многие вещи «захардкожены» внутри NeuVector и любое изменение параметров окружения может сделать его неработоспособным.
Платформа использует собственную инсталляцию Consul и сохраняет настройки всех контроллеров в единую директорию с требованием mode: ReadWriteMany для PVC. В результате выбор совместимых решений хранения данных сильно ограничен. Ошибка конфигурации может привести к повреждению правил и политик безопасности.
NeuVector не поддерживает такие современные технологии, как eBPF и Opentracing. Это снижает возможности обнаружения угроз и интеграции с внешними системами мониторинга.
Кроме того, DaemonSet-агенты NeuVector требуют значительных ресурсов, особенно в крупных кластерах, поскольку выполняют инспекцию всего трафика в режиме DPI. Такие технологии, как eBPF, способны реализовать сетевую безопасность намного экономичнее. Плюс для работы с полным функционалом агенты должны запускаться в privileged-режиме, что увеличивает поверхность атаки.
2. Ограниченная совместимость и интеграция
Если со старыми версиями Kubernetes всё в порядке, то поддержка новых релизов нередко сильно запаздывает.
В большинстве облачных сред NeuVector либо не работает, либо работает с серьёзными ограничениями, а ещё он не интегрируется с Cloud Native-инструментами.
3. Проблемы интерфейса и документации
Пользовательский интерфейс NeuVector устарел и неудобен в повседневной работе. В нём отсутствует удобный и полнофункциональный механизм фильтрации: доступные фильтры лишь частично покрывают рутинные задачи, а их настройка вызывает затруднения и ограничивает пользовательские сценарии. Также в интерфейсе нельзя посмотреть подробности при возникновении ошибок. Если приложение выдало ошибку при сканировании, деталей вы не найдёте.
Кажется, что часть функционала нагромождалась друг на друга, и в итоге получилась сборная солянка. Интеграция с SSO (например, Rancher и SUSE SSO) реализована фрагментарно, поддержка LDAP/OIDC нестабильна и регулярно требует повторного логина. Кстати, результаты поиска в документации по «Single sign on» сводятся исключительно к Rancher, хотя SSO — устоявшийся термин.
Документация NeuVector в целом неоднородна: архитектура и основные компоненты описаны достаточно хорошо, но многие примеры настроек устарели. Ответы в issue-системе часто шаблонны и не содержат решений по существу.
Более того, REST API не покрывает весь доступный функционал платформы. А это затрудняет автоматизацию и интеграцию с внешними системами.
4. Особенности Open Source-статуса
Формально NeuVector — это Open Source-платформа, но до покупки компанией SUSE проект был полностью закрытым. У него не сформировалось полноценное сообщество и мало активных контрибьюторов. SUSE делает ставку на Rancher Prime, а NeuVector остаётся на вторых ролях.
5. Ограничения security-функционала
Пожалуй, это последняя, но самая важная причина не использовать NeuVector в production. С описанным выше в целом можно смириться, но вот нюансы и ограничения security-возможностей хочется раскрыть подробнее.
5.1. Сфокусированность на сетевом трафике
NeuVector разрабатывался прежде всего как NGFW (Next-Generation Firewall) и IDS/IPS для контейнерной среды. Его основные функции — Deep Packet Inspection, межконтейнерная фильтрация по сетевым политикам и обнаружение сетевых атак.
Минусы такой архитектуры:
Легко обойти с помощью шифрования (например, внутрикластерных TLS/SSL-соединений).
Слабая реакция на современные атаки уровня хоста и ядра.
5.2. Ложные срабатывания и ограниченный coverage
Сигнатуры NeuVector охватывают только известные сетевые атаки. Поведенческий анализ относительно прост и часто выдаёт многочисленные false positives — особенно в крупных кластерах.
А ещё логика рабочих профилей (behavioral baseline) зачастую негибкая: настройки профилей плохо масштабируются при большом количестве микросервисов.
5.3. Уязвимость и риски самого NeuVector
NeuVector требует запуска агентов/демонов с привилегиями на каждом узле. Это расширяет поверхность атаки: если злоумышленник получит доступ к узлу — через эскалацию можно снизить уровень защищённости всего кластера. А сами агенты могут падать, оставлять незакрытые debug endpoints или не догружаться, что влечёт за собой слепые зоны в защите кластера.
5.4. Сканирование образов на уязвимости
База уязвимостей содержит небольшое количество операционных систем, пожалуй, только самые популярные: Debian, Ubuntu, SUSE, Red Hat Linux. Поддержка российских ОС отсутствует, как и информация из БДУ ФСТЭК России.
Расширять базу NeuVector своими силами будет довольно-таки сложно. Монолитная архитектура платформы не предоставляет механизмов для простой загрузки или подключения кастомных источников. Чтобы добавить поддержку новых ОС или источников уязвимостей, придётся разбираться с внутренней логикой продукта и делать свою сборку NeuVector.
Про поддержку самоподписанных CA-сертификатов я уже писал выше, но повторюсь — её просто нет.
5.5. Режим self-learning
Этот режим даёт иллюзию защищённости. Настройка с его помощью выглядит очень лёгкой и формирует ложное чувство контроля. Однако если в режиме обучения NeuVector не успел обнаружить какую-то активность, например отчёт, который делается раз в месяц, то она будет заблокирована.
В крупных системах генерируется очень много правил, и на их аудит нужно потратить немало времени. Пожалуй, единственный действенный способ — формировать правила в dev-кластере и вручную, с полным пониманием процесса, переносить их в prod.
6. Плохая поддержка IaC
NeuVector использует собственную ролевую модель. Для неё нужно настроить mapping с OIDC, LDAP/AD или SAML, а это далеко не тривиальная задача. Все правила доступа в NeuVector сохраняются во внутреннем формате, и хотя их можно выгрузить как манифесты для Custom Resource, эти манифесты откровенно сложно читать.
Всё это указывает на то, что инструмент изначально проектировался вне контекста Kubernetes и IaC-практик. Поддержку K8s добавили постфактум — с множеством нюансов и архитектурных компромиссов.
Современные альтернативы
Для обеспечения комплексной безопасности Kubernetes мы рекомендуем использовать зрелые открытые инструменты:
Falco — мировой стандарт для runtime security, поддерживает event-based-мониторинг, легко расширяется и интегрируется.
Trivy — лидер по сканированию образов контейнеров, включая поиск уязвимостей, проблем с конфигурациями и секретами. Поддерживает CIS Benchmark.
OPA/Gatekeeper — основной инструмент для реализации политик безопасности и контроля комплаенса.
Cilium Network Policy — современный инструмент для контроля и блокировки нежелательного сетевого трафика, обеспечивает гибкие eBPF-политики и высокую производительность.
Эти решения активно применяются в Deckhouse Kubernetes Platform, проверены на большом количестве кластеров, поддерживают российские ОС и обеспечивают высокий уровень защиты Cloud Native-инфраструктуры. На первый взгляд может показаться, что они не дают возможность аудита. Однако, помимо метрик и алертов, перечисленные инструменты формируют таблицы с отчётами в Grafana Dashboard, которые легко можно сохранить в PDF и использовать в отчёте или при согласовании.
Заключение
NeuVector может быть полезен в отдельных случаях — как инструмент для быстрого знакомства с основами сетевой безопасности Kubernetes или организации базовой защиты при отсутствии профильных специалистов. Однако мы не рекомендуем использовать NeuVector в production-средах, потому что его архитектурные, функциональные и интеграционные ограничения не позволяют решить современные задачи безопасности контейнеризированных и облачных сред на должном уровне.
Использование NeuVector может создавать ложное ощущение защиты и приводить к пропуску реальных угроз в вашей инфраструктуре. Предпочтение должно отдаваться современным Open Source-решениям, таким как Falco, Trivy, OPA/Gatekeeper и Cilium Network Policy. Они обеспечивают гибкость, масштабируемость и соответствие актуальным требованиям безопасности.
Отметим, что NeuVector поставляется у нас «as is», мы не отвечаем за его развитие, поддержку или исправление ошибок, несмотря на то, что он включён в наш модуль.
P. S.
Читайте также в нашем блоге: