Автор: DevOps Team Leader компании Hostkey Никита Зубарев

Мы уже рассказывали о нашем опыте интеграции FreeIPA с Active Directory в нескольких прошлых статьях (здесь и здесь), а теперь настало время авторизации IPMI-серверов.

LDAP стал стандартом де-факто для служб аутентификации и авторизации. Популярные решения на базе LDAP, такие как FreeIPA, обеспечивают централизованное управление учетными записями и доступом. Это позволяет разработчикам программного обеспечения легко интегрировать аутентификацию через LDAP в свои приложения с помощью готовых клиентских библиотек.

Производители серверного оборудования также активно используют возможности LDAP. Например, Supermicro реализовала аутентификацию пользователей через FreeIPA в своей системе IPMI для удаленного управления серверами. Это избавляет от необходимости создавать учетные записи во внутренней базе IPMI для каждого пользователя на каждом сервере.

Вместо аутентификации пользователя во внутренней базе данных пользователей IPMI, IPMI BMC может запрашивать FreeIPA. Пользователи, которым разрешен вход, идентифицируются по принадлежности к определенной группе безопасности. Доступ предоставляется любому пользователю, который является членом этой группы безопасности. Первым приоритетом является внутренняя база данных пользователей IPMI, вторым — внешние репозитории, в нашем случае FreeIPA.

При таком подходе в больших серверных инфраструктурах появляется единая точка аутентификации через LDAP. Это упрощает администрирование и повышает безопасность по сравнению с локальными учетными записями.

При большом и не очень парке железных серверов при автоматизации управления возникает потребность иметь «единую точку входа», которая предоставляет ряд преимуществ (например авторизации через LDAP). 

Используем прокси для интеграции с FreeIPA — есть много заготовок на Go, которые можно использовать с доработками, например yazynin/supermicro-bmcldap-freeipa или bmc-toolbox/bmcldap. Мы использовали bmc-toolbox. Потребовалось модифицировать механизм авторизации в соответствии с задачей и доработать логику запросов к FreeIPA.

Мы изменили схему авторизации пользователей, чтобы она соответствовала принятым внутренним стандартам безопасности. Кроме того, мы добавили подстановку атрибута CN на UID при запросах к LDAP для согласования схем данных между IPMI и FreeIPA.

Благодаря этим доработкам удалось настроить интеграцию IPMI с централизованным каталогом FreeIPA и внедрить единую систему аутентификации пользователей на базе LDAP для удаленного доступа к серверам.

В проекте есть три протокола для Dell, HP и SuperMicro соответственно:

  • Версию для HP не трогали вообще, поскольку она у нас не используется.

  • Для интеграции с серверами Dell потребовалось внести изменения в логику запросов к LDAP относительно базовой версии для Supermicro. Во-первых, мы убрали использование атрибута memberOf, поскольку он не поддерживается на стороне Dell. Вместо него мы реализовали логику более сложных запросов к LDAP для определения групп пользователя. Во-вторых, пришлось модифицировать используемые атрибуты запросов, поскольку в базовой версии они были жестко привязаны к особенностям реализации Supermicro. Атрибуты были заменены в соответствии со схемой данных и требованиями Dell. Благодаря этим изменениям нам удалось адаптировать решение и настроить интеграцию IPMI серверов Dell с централизованным LDAP, несмотря на различия в реализации между разными производителями.

  • Была поправлена версия для Supermicro и для Dell, исправлены ошибки в именовании некоторых переменных конфига. Поскольку Supermicro не разделяет права пользователей по группам, а получает их из записи пользователя, этот механизм мы тоже переработали. Также мы добавили расширенное логирование, что упростило отладку и мониторинг.

Итак, собираем пакет (про нашу систему пакетов можно почитать в одной из прошлых статей) и на выходе получаем рабочий микросервис.

Для завершения интеграции осталось подключить все имеющиеся серверы к централизованной системе аутентификации на базе LDAP. Серверы в инфраструктуре классифицируются по типам (Supermicro, Dell и т. д.) с помощью тегов. Это позволяет получить их список программным путем через API.

Через утилиту SMCIPMITool подключаем серверы. Настройка производится в web-интерфейсе или с помощью командной строки:

#SMCIPMITool 192.168.0.1 ADMIN pass ipmi oem x10cfg ldap 1 1 636 ip_addr_proxy '' supermicro cn=supermicro,cn=bmcUsers

Для серверов Dell используется утилита racadm.

Создаем текстовый файл с таким содержанием:

/etc/inworker/ldap.cfg
[iDRAC.LDAP]
BaseDN=cn=dell
BindDN=dell
BindPassword=pass
CertValidationEnable=Disabled
Enable=Enabled
GroupAttribute=memberOf
GroupAttributeIsDN=Disabled
Port=636
SearchFilter=objectClass=posixAccount
Server=10.77.0.1
UserAttribute=uid
[iDRAC.LDAPRoleGroup.2]
DN=cn=dell,cn=ipmi_access,cn=groups,cn=accounts,dc=infra,dc=hostkey,dc=ru
Privilege=0x1ff  

Далее выполняем команду:

 racadm -r <ip of IPMI host> -u ADMIN -p <admin_password> set -f ldap.cfg

Что это и зачем это нужно

Реализации протокола IPMI и взаимодействия с LDAP у разных производителей серверного оборудования существенно различаются. Каждый вендор может предъявлять свои специфические требования к структуре каталогов LDAP, типам запросов, используемым атрибутам и прочим нюансам интеграции.

Одни производители поддерживают работу только с Active Directory, другие требуют наличия кастомных атрибутов для авторизации пользователей. Поддержка всех этих требований в рамках одного корпоративного LDAP-каталога часто оказывается крайне сложной и нецелесообразной задачей.

Для решения этой проблемы было разработано ПО bmcldap — прокси-сервер для интеграции IPMI и LDAP. Он выступает посредником между оборудованием и корпоративным каталогом, эмулируя работу LDAP-сервера с точки зрения BMC.

Bmcldap преобразует запросы от различных вендоров в стандартный LDAP-формат. Затем он выполняет нужные запросы к целевому каталогу и возвращает результат в виде, ожидаемом конкретной реализацией IPMI.

Таким образом решается проблема совместимости и появляется возможность использовать любой стандартный LDAP в качестве единого репозитория для аутентификации пользователей через IPMI в гетерогенной IT-инфраструктуре.

Логика работы

Для корректной маршрутизации запросов к LDAP в зависимости от производителя оборудования в строку поиска DN добавляется идентификатор вендора:

  • cn=dell — для устройств Dell;

  • cn=supermicro — для Supermicro;

  • cn=hp — для HP и т. д.

Например, для аутентификации на сервере Dell строка DN будет выглядеть так:

cn=dell,cn=bmcadmins,cn=groups,cn=accounts,dc=example,dc=com

Получив запрос с таким DN, прокси-сервер bmcldap определит, что необходимо обработать запрос специфично для Dell, и выполнит поиск в LDAP соответствующим образом.

При добавлении сервера в конфигурацию аутентификации через LDAP, ему назначается тег ldap. Это нужно для того, чтобы не обрабатывать такой сервер повторно при следующем запуске.

Такой подход позволяет гибко настраивать правила обработки запросов к LDAP в bmcldap на основе идентификатора производителя в DN-строке. Это упрощает поддержку разнородного оборудования от разных вендоров.

Вывод

Использование прокси-сервера bmcldap позволило решить проблему интеграции разнородных серверных платформ от различных производителей с единым корпоративным LDAP-каталогом для централизованной аутентификации пользователей.

Ключевым моментом стала маршрутизация запросов от BMC на основе идентификатора производителя в DN-строке LDAP-запроса. Это позволило реализовать специфическую обработку для каждого типа оборудования.

Были доработаны внутренние механизмы bmcldap для корректной работы с серверами Supermicro и Dell, устранены проблемы совместимости.

В результате все серверы были интегрированы с прокси-сервером bmcldap для аутентификации через LDAP с учетом особенностей различных реализаций IPMI. Это решение упростило администрирование и повысило безопасность доступа к серверам.

Гибкость реализации bmcldap позволяет в дальнейшем расширять поддержку новых платформ без изменения основной инфраструктуры LDAP.


Арендуйте выделенные и виртуальные серверы с моментальным деплоем в надежных дата-центрах класса TIER III в Москве и Нидерландах. Принимаем оплату за услуги HOSTKEY в Нидерландах в рублях на счет российской компании. Оплата с помощью банковских карт, в том числе и картой МИР, банковского перевода и электронных денег.

Комментарии (0)