Yandex BareMetal: как организовать безопасный доступ к KVM и не нарушить инфраструктуру
Неправильно настроенный доступ к оборудованию способен привести к инциденту, который уже нельзя будет быстро исправить. Известны ситуации, когда злоумышленникам хватало нескольких BMC-устройств, найденных обычным сканированием, чтобы получить контроль над крупной инфраструктурой. Поэтому удалённый доступ к KVM в сервисе выделенных серверов нельзя рассматривать как простую функцию "подключить консоль".
Меня зовут Павел Пушкарёв, я занимаюсь разработкой Yandex BareMetal - сервиса аренды физических серверов в Yandex Cloud. При создании платформы мы опирались на внутренний опыт работы Яндекса с оборудованием и старались сохранить уже проверенные подходы. Однако внешний сервис отличается от внутренней инфраструктуры: к серверу должны подключаться не только инженеры дата-центра, а правила доступа должны учитывать множество независимых пользователей.
Зачем пользователю нужен KVM
Физический сервер можно администрировать по сети, но сетевой доступ не всегда доступен. Например, пользователь может:
- установить собственную операционную систему;
- изменить сетевые настройки и потерять подключение;
- исправить конфигурацию загрузчика;
- проверить сообщения BIOS или UEFI;
- восстановить сервер после сбоя операционной системы;
- работать с дисками и RAID до запуска ОС.
Во всех подобных сценариях требуется консоль, доступная ещё до загрузки операционной системы. Именно такую возможность предоставляет KVM - удалённая передача изображения с экрана и нажатий клавиатуры.
На физическом уровне для KVM обычно нужны два канала: видео и USB. Передавать VGA или HDMI напрямую через сеть неудобно: для этого потребовалась бы дополнительная аппаратура. Поэтому в серверы устанавливают BMC - контроллер, который внутри машины эмулирует монитор и клавиатуру, а наружу предоставляет управление через Ethernet.
Почему одного IPMI недостаточно
IPMI предназначен для управления аппаратной частью сервера через BMC. С его помощью можно включить или выключить машину, получить данные о температуре, состоянии вентиляторов, питании и других компонентах. Протокол позволяет работать с оборудованием разных производителей по единой модели.
Однако передача изображения с экрана в классический IPMI не входит. KVM-подсистема долгое время оставалась зоной ответственности производителей оборудования. Каждый из них реализовывал её по-своему, а пользователю приходилось запускать специальное приложение.
Раньше наиболее распространённым вариантом были Java Web Start-программы. Браузер загружал JAR-файл, после чего локальное приложение подключалось к BMC по закрытому протоколу и отображало консоль. У такого решения было несколько серьёзных недостатков. Пользователю требовалось запускать непонятное приложение, а старые прошивки BMC часто зависели от давно устаревших версий Java и криптографических алгоритмов. Встречались даже подписи на основе MD4, которые современные операционные системы закономерно блокируют.
Позже индустрия перешла к HTML5. Браузеры научились быстро выводить изображение на canvas и поддерживать WebSocket, поэтому KVM стало возможным открывать прямо в веб-интерфейсе. Но это не устранило главную проблему: протокол, передаваемый через WebSocket, обычно остаётся закрытым и зависит от конкретного производителя BMC.
Ограничения инфраструктуры
При проектировании BareMetal пришлось учитывать несколько особенностей.
Во внутренней инфраструктуре Яндекса активно используется IPv6. При этом часть оборудования в IPMI-сети поддерживает только IPv4. Следовательно, требовался промежуточный слой, способный преобразовывать соединения между двумя версиями IP.
Кроме того, BareMetal должен был соответствовать общей модели безопасности облачной платформы. Нельзя было просто вывести IPMI-адреса в интернет или разрешить пользователю прямое соединение с management-сетью. Даже если сервер физически принадлежит арендатору, его BMC находится внутри общей инфраструктуры дата-центра и не должен становиться доступным напрямую.
Наконец, оборудование в парке неоднородно. Серверы разных поколений используют различные версии прошивок, форматы авторизации и реализации KVM. Унифицировать всё это на стороне пользовательского интерфейса невозможно, поэтому понадобился отдельный сервис-посредник.
Архитектура IPMI Proxy
Для решения задачи мы использовали IPMI Proxy. Его роль - скрыть различия между платформами оборудования и предоставить пользователю единый способ подключения.
На каждое пользовательское соединение запускается отдельный Docker-контейнер. Внутри него работает необходимый набор компонентов: прокси для IPMI, адаптер для KVM и логика преобразования протоколов. Контейнер получает доступ только к конкретному BMC и существует ограниченное время.
Такой подход даёт несколько преимуществ:
1. Изоляция подключений. Пользовательские сессии не смешиваются между собой.
2. Ограничение области доступа. Контейнер может обращаться только к назначенному серверу.
3. Унификация оборудования. Внешнему клиенту не нужно знать производителя и модель BMC.
4. Упрощённое удаление доступа. Завершение сессии уничтожает временный окружение.
5. Контроль ресурсов. Для контейнера можно задать лимиты CPU, памяти и сетевых операций.
Само соединение проходит через контролируемый шлюз, а не напрямую из браузера в IPMI-сеть. Пользователь получает временный токен или иной ограниченный механизм авторизации, который нельзя использовать для доступа к другим серверам.
Почему нельзя ограничиться сетевым фильтром
Одного firewall недостаточно. Даже если открыть IPMI только для нескольких адресов, остаются риски:
- уязвимости в прошивке BMC;
- слабые или повторно используемые пароли;
- ошибки в ACL;
- возможность атаковать соседние management-интерфейсы;
- несовместимость старых реализаций с современными средствами защиты;
- сохранение активной сессии после завершения аренды.
Поэтому защита должна строиться слоями. На сетевом уровне ограничивается маршрут, на уровне прокси проверяется принадлежность сервера пользователю, а на уровне контейнера дополнительно изолируется процесс.
Важно также не передавать наружу реальные IP-адреса BMC. Пользователь должен работать с абстрактной конечной точкой сервиса, тогда изменение внутренней топологии или замена оборудования не потребует менять клиентскую логику.
Управление жизненным циклом сессии
Безопасность зависит не только от момента подключения, но и от корректного завершения сеанса. Для KVM необходимо контролировать:
- срок действия токена;
- максимальную продолжительность подключения;
- отсутствие активности;
- повторное использование сессии;
- завершение контейнера при отзыве доступа;
- очистку временных секретов и журналов.
Если пользователь закрыл вкладку браузера, это не всегда означает корректное закрытие WebSocket. Поэтому система должна самостоятельно обнаруживать разрыв соединения и освобождать ресурсы. Иначе в инфраструктуре будут накапливаться "зависшие" контейнеры и активные прокси.
Отдельное внимание требуется уделить журналированию. В логах полезно фиксировать время подключения, идентификатор пользователя, сервер, результат авторизации и причину завершения. При этом нельзя записывать пароли, токены и содержимое консольной сессии без отдельного обоснования.
Доступ по принципу минимальных полномочий
Пользователь должен иметь возможность управлять только тем сервером, который он арендует. Проверка права доступа должна выполняться не единожды при открытии страницы, а на каждом важном этапе: при создании прокси, установлении соединения с BMC и продлении сессии.
Полезно разделять права на просмотр консоли, отправку ввода и выполнение операций питания. Перезагрузка или выключение сервера способны привести к потере данных, поэтому такие действия желательно защищать дополнительным подтверждением.
Не следует доверять параметрам, которые приходят из браузера. Идентификатор сервера, адрес BMC и параметры подключения должны определяться серверной частью по данным биллинга и каталога ресурсов.
Что получилось в итоге
История с KVM показала, что добавление "простого" доступа к физическому серверу быстро превращается в задачу на стыке сетей, безопасности, контейнеризации и совместимости оборудования.
IPMI Proxy позволил скрыть особенности разных BMC, учесть переход между IPv4 и IPv6 и встроить BareMetal в общую модель безопасности облака. Изолированные контейнеры ограничили область действия пользовательских подключений, а временные сессии снизили риск сохранения доступа после завершения работы.
Главный вывод заключается в том, что KVM нельзя публиковать напрямую. Надёжная схема должна включать промежуточный сервис, строгую авторизацию, минимальные права, сетевую изоляцию, контроль срока жизни соединения и полное уничтожение временной инфраструктуры после завершения сеанса. Именно такой набор мер позволяет дать пользователю полноценный доступ к физическому серверу, не превращая management-сеть дата-центра в новую точку атаки.