Сохраняем модель безопасности при переносе ВМ в Kubernetes

26 мая 2026 г.

#cilium#kubernetes#kubevirt#migration#network-security#nsx#vmware

Ситуация

Решение принято. VMware-инфраструктура переезжает в Kubernetes. Причины разные — ценовая политика Broadcom, модернизация, или и то, и другое. Платформа меняется, но ваша модель безопасности остаётся той же. И она построена вокруг NSX: микросегментация, distributed firewall, identity-aware политики между ВМ.

Вопрос не в том, можно ли запустить ВМ в Kubernetes — KubeVirt давно умеет это, и довольно хорошо. Вопрос в том, не теряем ли мы при этом уровень безопасности, к которому привыкли в NSX.

Что даёт NSX, чего нет в стандартном Kubernetes

NSX предоставляет четыре фундаментальных вещи, которые в чистом K8s-нетворкинге отсутствуют:

  • Distributed firewall на уровне vNIC — политика применяется к каждому интерфейсу ВМ, а не к Pod-у. Трафик внутри одного хоста тоже фильтруется.

  • Identity-aware tags — политики основаны не на IP, а на тегах ВМ (role:web, env:prod, pci:in-scope). Перенос ВМ на другой хост ничего не меняет.

  • Service insertion — IDS/IPS, L7-firewall, anti-malware подключаются в data-path прозрачно.

  • Centralized policy management — единая консоль для тысяч правил с автоматическим compile-down в hardware-friendly формат.

Kubernetes NetworkPolicy — это namespace-scoped allow-list по pod-селекторам и портам. Этого недостаточно для того, что NSX делает по умолчанию.

Три подхода к воспроизведению NSX-модели на K8s

Подход 1: KubeVirt + Cilium с identity-aware политиками

[Cilium](https://cilium.io/) — eBPF-CNI, который умеет:

  • Identity-based policy через labels (аналог NSX tags). Политика «role:web → role:db на 5432» применяется к Pod-у/VMI независимо от IP.

  • L7-aware policy — HTTP/gRPC методы и пути.

  • Encryption (WireGuard/IPsec) между нодами автоматически.

  • ClusterMesh для multi-cluster политик — аналог cross-vCenter NSX.

Комбинация KubeVirt + Cilium даёт примерно 80% NSX-возможностей в чистой K8s-парадигме. Минусы: нет IDS/IPS из коробки (нужен service-mesh или sidecar), нет визуального policy-builder уровня NSX Manager.

Подход 2: NSX-T поверх Kubernetes (VMware Container Networking)

VMware официально поддерживает NSX-T как CNI для K8s через [Antrea](https://antrea.io/) (open-source проект, который VMware купила). Antrea + NSX даёт:

  • Те же NSX-теги и distributed firewall policies, что и для ВМ.

  • Единую policy plane между legacy-VMware и K8s-кластерами — миграция инкрементальна.

  • Service insertion для трафика подов (партнёры — Palo Alto, Check Point).

Минус — vendor lock-in именно к VMware/Broadcom. Если вы уходите от VMware, этот вариант обнуляет цель миграции.

Подход 3: Service mesh поверх любого CNI

Istio / Linkerd / Cilium Service Mesh добавляют:

  • mTLS между всеми pod-ами — authn-based, не IP-based.

  • AuthorizationPolicy на уровне HTTP/gRPC.

  • Observability (трассы, метрики) уровня L7.

Для ВМ в KubeVirt service mesh применяется к VMI так же, как к подам, — через sidecar или ambient-mode (Istio 1.20+).

Что выбирать на практике

Если решающие критерии — скорость миграции и сохранение знакомой консоли, и вы остаётесь в VMware-экосистеме, идите через Antrea+NSX. Если уходите от VMware совсем — Cilium с identity-aware policies даёт прямой аналог микросегментации, дополненный service mesh для L7. Третий путь («тонкий» K8s NetworkPolicy + ad-hoc сегментация) на проде с тысячами ВМ не работает — слишком много IP-зависимостей.

Чек-лист перед миграцией

  1. Выпишите из NSX-Manager все теги, которыми оперируют ваши политики. Это и будет основной словарь labels для будущих VMI.

  2. Соберите матрицу east-west трафика — какие сегменты к каким ходят. Без этого вы получите либо дырявый allow-all, либо deny-all с продакшен-инцидентами.

  3. Решите вопрос с хостовой изоляцией: KubeVirt запускает ВМ как pod, и контейнер-runtime становится частью attack-surface. Если в NSX у вас был hypervisor-level isolation между ВМ разных tenant’ов — на K8s это означает отдельные node-pools (или physical hosts) + node-affinity по tenant-таге.

  4. Запланируйте параллельную работу старого и нового. NSX policies экспортируются в JSON через API; их нужно перевести в Cilium CiliumNetworkPolicy (или Antrea AntreaPolicy) полу-автоматически, с обязательным код-ревью каждого правила.

Безопасность — это не «дотянем потом»

Типичная ошибка миграции — вынести ВМ на K8s «как есть» с дефолтной allow-all-сетью, обещая «потом докрутить политики». Это потом не наступает: правил быстро становится столько, что новые добавляются хаотично, а старые никто не трогает из страха что-то сломать.

Подход с NSX-уровнем безопасности с первого дня означает: миграция конкретной ВМ не закрыта, пока её эквивалентные политики не воспроизведены в K8s и не валидированы автоматическим тестом east-west трафика.

Похожее