Я сделаю свои групповые политики – с наследованием и фильтрами

Привет Хабр! Я Дмитрий Закорючкин, в компании Avanpost я занимаюсь развитием нашей службы каталогов, Avanpost  Directory Service.

Сегодня я хотел бы поговорить о групповых политиках и их применимости в Linux-мире. Тема для меня близкая не только в связи с моей текущей деятельностью: так сложилось, что практически всю свою карьеру я так или иначе имел дело с AD DS, так что, надеюсь, рассказ предстоит интересный.

Групповые политики, что это?

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

{групповые политики MS AD – знакомые до боли}

Исторически групповые политики (часто, хоть и не совсем верно, сокращаемые до GPO) стали первым массовым средством для управления компьютерным парком в Windows-среде, представляя из себя эволюцию локальных политик безопасности (Local Security Policy), глубоко интегрированную со службой каталогов Active Directory. Как и в локальных политиках безопасности, настройки групповых политик чаще всего соответствуют определенным ключам реестра Windows (есть, конечно, ещё и Group Policy Preferences, но это отдельная история, о которой чуть позже). Одним из немаловажных факторов является ещё и то, что многие групповые политики блокируют интерфейс пользователя, не позволяя изменить определенные в них настройки.

Если же говорить о сценариях использования, то основными можно считать управление параметрами безопасности на серверах и рабочих станциях (например: каким требованиям должен соответствовать пароль пользователя, кто может выполнять перезагрузку системы или, например, требовать использовать смарткарту для интерактивного входа) и настройку пользовательского окружения (подключить сетевой принтер, диск или просто добавить закладку в браузер). Что не мешает, впрочем, в некоторых организациях использовать их вообще для всего, вплоть для распространения софта (для чего политики, пожалуй, наименее удобны).

За счет иерархической структуры каталога групповые политики обеспечивают простоту и интуитивность применения настроек: вводим  компьютер в домен и он получает настройки по умолчанию.  Переносим компьютер в подразделение (OU), к которому привязаны нужные политики, и получаем машину, настроенную для задач какого-либо отдела. И то же самое с пользователями – какой user experience получит наш сотрудник зависит от того, в каком подразделении он находится в каталоге, что очень удобно для подключения принтеров, сетевых папок и других подобных задач. *И я здесь осознанно не говорю о всевозможных фильтрах и привязке политик к сайтам, чтобы не затягивать вступление больше необходимого.

Что же отличает GPO от других систем управления конфигурацией, таких как SCCM или, например, Ivanti EPM.

·       Легковесность – GPO не требует дополнительной серверной инфраструктуры или отдельных агентов на управляемых машинах, а за счет того, что работает в pull режиме с минимальным фидбеком, практически не нагружает сервера.

·       Глубокая интеграция с доменной иерархией – хотя другие системы могут создавать коллекции на базе информации из каталога, такой простоты и прозрачности назначения настроек как GPO они не обеспечивают.

·       Спектр решаемых задач – GPO хороши для применения настроек безопасности и создания пользовательского окружения, в то же время, как минимум, не оптимальны для распространения ПО и совершенно не применимы в PXE сценариях, где как раз отлично себя показывают решения вроде SCCM.

{ещё одна задача, которую решает SCCM, а не групповые политики – управление обновлениями}

Зачем это в Linux?

Строго говоря, в Linux-мире давно сформировались свои подходы к управлению конфигурациями, их демонстрируют такие решения как Ansible, Puppet, Salt Stack и им подобные, но в целом все они ближе именно к SCCM, нежели к GPO, если сравнивать с Windows экосистемой. И пока мы не начали иметь дело с большими парками именно рабочих станций на базе Linux, этого было достаточно. Ansible замечательно справлялся с безагентским управлением серверной инфраструктурой, Puppet и Salt не менее успешно справлялись с этой задачей при помощи агентов.

Сама потребность в групповых политиках для Linux-инфраструктуры появилась вместе c массовым внедрением Linux АРМ и актуализацией ключевых сценариев использования GPO – созданием пользовательского окружения и контролем параметров безопасности для большого количества хостов.

Первое, с чем мы сталкиваемся при попытке решить эти задачи стандартными средствами Linux, – масштабирование системы, которая отлично справлялась с сотнями серверов на десятки тысяч рабочих станций. Это – совершенно нетривиальная задача (что особенно больно, если на выходе нам всего-то и нужно подключить пару дисков, принтер и создать ярлык на рабочем столе), здесь бы как раз хотелось иметь максимально легковесную систему, желательно вовсе не требующую отдельной инфраструктуры. Если же говорить о менее крупных инфраструктурах, то здесь стандартные средства Linux оказываются просто напросто слишком трудоемки в реализации, особенно если сравнивать их с GPO из Windows мира, которые настраиваются как раз таки достаточно быстро и интуитивно.

*На самом деле небольшая часть функционала групповых политик для Linux-инфраструктуры реализуется в ldap каталогах – это парольные политики, политики sudoers и правила HBAC (host based access control), но и это лишь капля в море и только в разрезе настроек безопасности.

Как это будет работать?

Ну и наконец разобравшись с тем, что из себя представляют GPO, и зачем они в Linux-инфраструктуре, я предлагаю наконец разобрать с реализацией этого функционала. При разработке Avanpost DS мы провели достаточно большой анализ этого вопроса и теперь можем поделиться своим опытом.

Первое, что бросается в глаза, когда мы говорим о групповых политиках для Linux, это то, чем они управляют. Как я писал выше, большая часть политик Windows это управление определенными ключами реестра, в Linux, естественно, никакого реестра нет, и вместо ключей реестра в качестве единицы конфигурации у нас чаще всего выступает параметр в конфигурационном файле. И здесь как раз групповые политики Linux ближе к Group Policy Preferences из MS AD, которые среди прочих настроек имеют достаточно гибкие возможности управления файловой системой. Соответственно, основой групповых политик для Linux должны стать как раз механизмы управления различными конфигурационными файлами.

{политика управления файловой системой в Avanpost DS}

Если же говорить о методах реализации, начать стоит с очевидного – групповые политики должны быть частью службы каталогов, что ясно уже из определения GPO   (в противном случае мы получаем скорее SCCM, отличный продукт, но, как мы уже выяснили, нужен он для других задач), собственно это и привело нас к необходимости реализации полноценных групповых политик в своей службе каталогов. Это позволяет решить сразу несколько задач:

·       Плотная интеграция с доменной иерархией – когда система управления конфигурацией является частью каталога, мы совершенно логично получаем в свое распоряжение оргструктуру каталога для назначения политик на разных уровнях иерархии (механизм селектора групповых политик).

·       Использование существующей инфраструктуры – служба каталогов есть практически в каждой IT-инфраструктуре, и если  система управления является её частью, то нам не нужно ничего дополнительно разворачивать.

·       Простота масштабирования – вытекает из предыдущего пункта, в таком случае система управления масштабируется вместе со службой каталогов за счет развертывания дополнительных контроллеров домена.

Следующий вопрос в том, за счет чего реализовывать этот функционал – прикручивать к каталогу Ansible/Puppet/Salt или писать своё решение. Ответ на него уже не так очевиден, и здесь мы в своё время проверили несколько гипотез.

В случае использования сторонней системы управления конфигурациями для реализации функционала групповых политик служба каталогов выступает как хранилище плейбуков/манифестов и как селектор групповых политик, выполняя трансляцию привязки компьютеров и пользователей к подразделениям в сопоставление конкретных хостов с конкретными конфигурациями. В первом релизе Avanpost DS мы так и сделали, реализовав политики на базе Puppet, сочтя этот путь более быстрым и перспективным (ведь в таком случае уже есть готовые механизмы применения огромного количества настроек, для разных версий ОС). Но, как оказалось, данный путь не лишён своих недостатков – использование сторонней системы привело к значительному усложнению архитектуры, усложнению траблшутинга и увеличению количества точек отказа. Плюс ко всему такой подход не позволял сохранить простоту масштабирования каталога, размещать Puppet Master на каждом контроллере домена, да ещё со своим инстансом базы данных оказалось достаточно накладно, Puppet должен был работать на выделенных серверах – в итоге мы получили скорее SCCM нежели GPO в плане сложности архитектуры и управляемости. Совершенно логично, что такое решение нас не удовлетворило и мы решили проверить следующую гипотезу.

Если не подходят готовые решения (а Puppet по итогам первичного тестирования лучше всех из готовых решений ложился на модель групповых политик), остается либо форкать то, что есть (и серьезно дорабатывать напильником), либо писать свои политики. При том, что трудозатраты на доработку и перспективы дальнейшей поддержки того же Puppet или Salt Stack, по сравнению с разработкой собственного решения, выглядели совершенно непривлекательно (и это уже не говоря о вопросах владения кодом), выбор в сторону разработки собственного решения становится очевиден. И вот здесь уже удовлетворяются все условия задачи:

·       Использование существующей инфраструктуры. Групповым политикам собственной разработки не требуется отдельная серверная инфраструктура, все, что нужно, хранится в ldap каталоге, а на стороне АРМ функционал реализуется в рамках доменного клиента.

·       Легковесность. Здесь мы сами вольны реализовать механизмы получения и  обработки политик, так как это меньше всего повлияет на инфраструктуру, посему требования к pull режиму получения политик, кешированию и обработке на стороне клиента закрываются легко. Такая реализация политик позволяет не нагружать серверную и сетевую инфраструктуру.

·       Масштабирование и балансировка нагрузки вместе с каталогом. При такой плотной интеграции политик с каталогом мы можем использовать для масштабирования и балансировки нагрузки те же методы что и сам каталог, а именно балансировку по srv записям (в том числе и для локализации служб по сайтам каталога) и масштабирование за счет развертывание новых контроллеров.

·       Гибкое и интуитивное назначение политик в оргструктуре. За счет плотной интеграции с каталогом мы можем позволить себе механизм селектора групповых политик сделать намного более гибким, не создавая дополнительной нагрузки на каталог и не усложняя архитектуру. Например, здесь легко реализуются такие функции  как фильтры безопасности, блокировка наследования и форсированные линки из групповых политик MS AD.

Такой подход несомненно влечет за собой и некоторые сложности, в первую очередь, это необходимость тестирования всех возможных настроек на всех поддерживаемых ОС, что особенно актуально, если служба каталогов не ограничивается в поддержке каким-либо одним дистрибутивом (а в случае Avanpost DS это как минимум несколько версий Alt, Astra, РЕД ОС, МСВСфера, так что трудозатраты немалые), однако плюсов оказалось больше.

{привязка политик к оргструктуре в Avanpost DS}

 

Что в итоге? Групповые политики в Linux действительно оказались нужны, особенно в реалиях импортозамещения. Puppet / Salt / Ansible и им подобные для реализации политик подходят плохо, у них своя парадигма управления компьютерным парком, ближе к SCCM, реализация политик на их базе выглядит как натягивание совы на глобус. За счет собственной реализации групповых политик в Avanpost DS мы смогли воспроизвести систему управления конфигурациями “как в AD” – интуитивную, легковесную и с минимальным воздействием на инфрастурктуру, что и считаем лучшим решением этой задачи. Ну, а если у Вас есть другое мнение на данный счет, приглашаю обсудить его в комментариях.