vSphere 6.5 U1: переходим на HTML5-клиент и включаем Encrypted vMotion

Когда в январе мы писали про vSphere 6.5 GA, честно оговорились: HTML5-клиент пока не покрывает всё, что умел Flash-вариант, и часть задач придётся делать в старом Web Client. Update 1 изменил расклад достаточно, чтобы перестать смотреть на Flash-клиент как на основной инструмент.

VMware выпустила U1 в конце июля. Патч закрывает несколько CVE в ESXi и vCenter (из которых пара касается несанкционированного доступа к управляющим интерфейсам), но главное для нас - два операционных улучшения: HTML5 vSphere Client серьёзно прибавил по охвату функциональности, и Encrypted vMotion наконец перестал преподносить сюрпризы.

HTML5-клиент: от «почти работает» к «основной»

В 6.5 GA HTML5-клиент покрывал процентов восемьдесят ежедневных задач. U1 подтянул оставшееся: теперь из HTML5 доступны расширенные настройки распределённых коммутаторов, большинство операций с vSAN (storage policies, disk groups, мониторинг), работа с certificates и кастомизированными атрибутами. Список неперенесённого сократился до относительно нишевых вещей.

Мы решили зафиксировать это в виде явного правила для команды: Flash-клиент открывается только для конкретных операций из согласованного списка. Не «пробуй сначала HTML5», а именно инвертированная логика - Flash-клиент как исключение, HTML5 как норма.

Практическая причина проста. Flash в браузерах живёт всё хуже: Chrome давно переключил на «нажми чтобы воспроизвести», Firefox идёт туда же, и это не настройка которую удобно держать включённой. На ряде корпоративных ноутбуков приходилось дополнительно убеждать браузер что этот Flash-плагин разрешён именно для этого хоста. HTML5-клиент открывается как обычная страница и работает.

Список операций, которые пока остаются во Flash-клиенте, у нас получился такой:

• некоторые операции с Host Profiles (часть UI там ещё не перенесена)
• управление лицензиями через vCenter (мелочь, но сидит в Flash)
• отдельные разделы Advanced System Settings на хостах при нестандартных конфигурациях

Список небольшой, и мы его ведём - чтобы при следующем апдейте сверить что из него ушло.

Encrypted vMotion: включаем на кластерах с конфиденциальными ВМ

Encrypted vMotion появился ещё в 6.5 GA, но мы его тогда не трогали. Миграция ВМ между хостами без шифрования означает, что трафик vMotion - по сути, дамп оперативной памяти работающей машины - идёт по сети в открытом виде. В изолированной management-сети, куда нет доступа извне, это обычно не приоритет. Но у нас есть кластеры, где крутятся ВМ с данными, на которые распространяются требования по защите: 152-ФЗ, финансовая информация, ВМ с ключевым материалом.

В 6.5 GA Encrypted vMotion иногда давал странные вещи при определённых конфигурациях сети и под нагрузкой - community-отчёты об этом были. В U1 это выправили, и наши тесты это подтвердили: несколько десятков миграций на тестовом кластере прошли без инцидентов, нагрузка на процессор хостов выросла незначительно.

Настройка работает на уровне виртуальной машины через три режима:

• Disabled - шифрование vMotion не используется (дефолт для существующих ВМ)
• Opportunistic - шифруется если оба хоста поддерживают, иначе миграция проходит без шифрования
• Required - миграция запрещена если целевой хост не может обеспечить шифрование (ESXi 6.5+ обязателен)

Мы выбрали Required для нужных ВМ. Opportunistic кажется разумным компромиссом, пока не разберёшься в деталях: если вдруг в кластере завалялся хост на более старой версии ESXi, миграция на него пройдёт без шифрования, и вы об этом не узнаете из предупреждений. Required режим ломает такую миграцию явным сообщением об ошибке - это лучше чем тихий откат к незащищённому каналу.

Параметр выставляется через Edit Settings ВМ -> вкладка VM Options -> Encryption -> vMotion Encryption. Либо через PowerCLI массово, что удобнее если машин больше десятка:

Get-VM -Name $vmNames | ForEach-Object {
    $spec = New-Object VMware.Vim.VirtualMachineConfigSpec
    $spec.migrateEncryption = [VMware.Vim.VirtualMachineConfigSpecEncryptedVMotionModes]::required
    $_.ExtensionData.ReconfigVM($spec)
}

На кластерах где включили Required - убедились заранее, что все хосты на ESXi 6.5 U1. Один хост с более старой версией ESXi в кластере сломает vMotion для защищённых ВМ и удивит оперативного дежурного в самый неподходящий момент.

Патчи CVE: что именно закрыто

U1 закрывает несколько уязвимостей, из которых выделим две:

CVE-2017-4924 - Out-of-bounds write в SVGA-устройстве ESXi. Теоретически позволяет коду внутри ВМ влиять на хост через виртуальный видеоадаптер. CVSS 8.8, но требует выполнения кода внутри гостя - то есть вектор не сетевой, а через уже скомпрометированную машину.

CVE-2017-4925 - NULL pointer dereference в VMXNET3. DoS для хоста из гостевой ОС. Менее критично с точки зрения конфиденциальности, но падение хоста - это уже availability.

Для обоих нужно обновить ESXi. Обновление через Update Manager штатное: Baseline на 6.5 U1, сканирование, remediate поочерёдно с DRS-эвакуацией. Хосты уходят на перезагрузку по одному, ВМ не простаивают.

Итог рабочего месяца

По факту U1 сделал два дела: дал нам повод окончательно сформулировать политику по клиентам (HTML5 основной, Flash по списку) и дал достаточно уверенности в Encrypted vMotion, чтобы включить его там, где это нужно по задаче, а не откладывать до следующего апдейта.

Для managed-проектов на vSphere это скорее операционная точность, чем революция - тихо закрыть дыры и зафиксировать хорошую практику, пока есть повод.

Flash-клиент в итоге превращается в легаси-инструмент с известным сроком жизни - и хорошо, что переход происходит постепенно, а не одним резким срезом.