Система централизованного управления авторизацией пользователей на FreeIPA в Docker
На волне популярности Docker на Хабре, после участия в некоторых дискуссиях в комментариях относительно Docker, и в связи с недавней необходимостью настроить централизованную авторизацию для кластера Linux машин, я решил написать небольшую заметку. Здесь будет показан яркий, на мой взгляд, пример применения Docker’a для небольшой частной задачи.
Вот так, кстати, выглядит FreeIPA WebUI (официальное демо) (кликабельно):
Какие задачи я хотел решить при помощи FreeIPA:
- Иметь возможность создавать/изменять/удалять акаунты пользователей централизовано, а не на каждом отдельном сервере
- Централизованные плавила для sudo
- В последствии мы подключим к этой системе ещё и VPN авторизацию, а потом может и другие внутриофисные сервисы
Да, скорее всего FreeIPA в нашем случае это выстрел пушкой по воробьям, но с другой стороны — альтернатив что-то не видно. Я рассматривал такие варианты: NIS (по-моему он уже давно должен отправиться на отдых), OpenLDAP +… +… (не очень дружелюбно, да и FreeIPA в итоге под собой имеет LDAP, только нам не приходится с ним иметь дело напрямую), тут перечень заканчивается, я не нашёл ничего больше.
Настройка сервера
Перечень используемых технологий:
- FreeIPA — открытый проект компании RedHat, который объединяет в себе множество других открытых проектов: 389 Directory Server, MIT Kerberos, NTP, DNS (bind), Dogtag certificate system, SSSD и другие. При этом у данного решения есть Web UI, CLI, XMLRPC, JSONRPC API и Python SDK.
- Dnsmasq — легковесный DNS сервер (позже я объясню зачем мне он нужен был в дополнение к bind, который используется в FreeIPA).
- Docker — open-source платформа, автоматизирующая развертывание приложений в легковесные, переносимые, самодостаточные контейнеры, которые могут без изменений переноситься между серверами. © Используем Docker и не волнуемся о vendor-lock
FreeIPA, в следствие того, что это продукт RedHat, естественно умеет хорошо разворачиваться на CentOS и Fedora и практически никак не разворачивается на других дистрибутивах. (прим. Я не особо задавался целью, поэтому может и есть где-то инструкции, но пакетов в Debian/Ubuntu для FreeIPA сервера нет, зато есть клиентский пакет freeipa-client , но об этом потом.)
Меня этот факт ни разу не расстроил, а, наоборот, воодушевил! Это же идеальная задача для Docker, когда на серверах Debian/Ubuntu/Gentoo/etc. То есть я мог взять базовый образ Fedora, поставить там нужные пакеты, собрать всё в кучу и запустить, НО ещё более приятной новостью для меня стал официальный Docker образ freeipa-server (есть у них и клиент, но меня интересовал вариант с клиентом на Ubuntu, поэтому я запускал ubuntu образ в Docker и таким образом моделировал и быстро начинал с начала для отладки процесса «с нуля»).
Вообще, запуск freeipa-server не вызвал никаких проблем, всё в соответствии с документацией к образу Docker’a:
- Создаём директорию, которая будет монтироваться в образ для конфигов FreeIPA, которые нужно оставлять после перезапуска (в документации предлагается использовать /var/lib/ipa-data/ , но я не люблю засорять систему, поэтому /opt/ ):
Добавим файл с опциями, которые будут использоваться при инсталяции freeipa-server:
Всё, запускаем (в доке не хватает проброса портов, хотя это и очевидно, что нужно сделать; стоит также отметить, что в доке написано, что нужно подключать раздел с постфиксом :Z:rw , но если у вас нет SELinux, вам эта опция не нужна (спасибо grossws)):
FreeIPA у себя в образе поднял целый зоопарк служб, в том числе и bind (DNS), который настроил по своему усмотрению (магия, которую практически невозможно повторить на других DNS). Для клиентов FreeIPA ожидается, что они будут иметь доступ к этому DNS, который ещё умеет как-то хитро failover обрабатывать, только вот в случае как здесь — всё в одном образе Docker я не очень вижу пользу с такого failover. Однако, я не стал идти на перекор и учёл пожелания разработчиков FreeIPA (кстати, это особенность Kerberos, всё-таки FreeIPA — просто объединяет множество пакетов).
Так вот, к чему я про DNS? Мне нужен был DNS внутри кластера, но мне категорически не хотелось влезать в bind внутри FreeIPA контейнера. Поэтому я решил воспользоваться проверенным решением — Dnsmasq. На Docker Hub есть минималистичный образ Dnsmasq, основанный на Alpine Linux — 6МБ.
Вот как я его подготовил:
- Создал директорию для конфигов:
Добавил туда конфиг dnsmasq:
Запускаем (DNS работает на 53/tcp и 53/udp портах, так что пробрасываем их, папку с конфигами):
Итого, у нас есть FreeIPA Server в одном контейнере и Dnsmasq в другом. Кстати, Dnsmasq, как можно было заметить, никак с bind DNS сервером FreeIPA ещё не взаимодействует.
Дальше я связал эти два сервиса в один docker-compose.yml :
Можно заметить небольшую магию с дополнительной опцией к команде dnsmasq, эта опция будет перенаправлять запросы к *.example.test на bind DNS, уставновленный в freeipa контейнере.
Удобство Docker Compose в данном конкретном случае в том, что его конфиг всё-таки удобнее читать, чем bash-скрипт с docker run . Да и лучше сразу делать хорошо. Сохраняем docker-compose.yml и запускаем:
C сервером, наконец, закончили.
Настройка клиентов
Тут у меня есть решение в 3 команды 🙂
- Нужно исправить /etc/hosts таким образом, чтобы первым в списке было полностью определённое имя домена (FQDN):
Настроить DNS (через /etc/network/interfaces или /etc/resolvconf/resolv.conf.d/head ) так, чтобы в /etc/resolv.conf появились следующие строки:
И теперь изменив пароль admin’a к FreeIPA в следующей команде, можете её запустить:
Здесь добавится PAM-модуль для автоматического создания домашних директорий, установится freeipa-client, запустится установка ipa-client, добавится сервис sudo в sssd.conf и перегрузятся sssd и ssh.
Вот и всё, теперь на этом хосте можно делать su/sudo/ssh, где пользователя при самом первом входе заставят сменить пароль, а при первом входе на новом хосте для пользователя будет автоматически создана домашняя директория из /etc/skel .
Выводы
Docker может упростить разворачивание сложных проектов в любой инфраструктуре. У Docker есть масса применений и это только одно из них.
В дальнейшем я, возможно, сподвигнусь написать о другом проекте, который интенсивно использует ограничения ресурсов, интегрированные в Docker (CPU, RAM).
Источник
Автоматизируем FreeIPA: как устанавливать клиентов с помощью Ansible и управлять DNS записями через Terraform
У нас в Altenar собралась достаточно большая и продвинутая команда разработчиков. За эти годы внутри компании накоплен разнообразный опыт в создании и развитии высоконагруженных систем. Поэтому время от времени коллегам хочется поделиться с миром своими знаниями. Регистрироваться на Хабре они пока не готовы, зато совсем не против материализовываться на моей странице. Надеюсь острой аллергии это у вас не вызывает. Если будут вопросы к материалу, смело оставляйте их в комментариях, обещаю молниеносно перенаправлять авторам статьи. Добро пожаловать за кат.
Привет, меня зовут Денис, и я около двух лет работаю DevOps инженером в компании Altenar. Наша инфраструктура располагается как в Google Cloud, так и в собственном облаке на базе VMWare, в котором находится более 200 серверов и виртуальных машин.
Когда количество Linux машин в компании достаточно велико, то рано или поздно возникает необходимость в централизованном управлении доступом к серверам и если в случае с Windows использование AD является индустриальным стандартом, то, когда дело доходит до Linux приходится использовать такие инструменты как FreeIPA.
FreeIPA (Free Identity, Policy and Audit) ─ это open-source решение для Linux (аналогичное MS Active Directory), которое обеспечивает централизованное управление учетными записями и централизованную аутентификацию.
Необходимо отметить, что у RedHat есть решение IdM, которое является частью RHEL. Они технически идентичны с FreeIPA и, можно сказать, что FreeIPA является upstream версией для IdM на которой обкатываются новые фичи (как Fedora для RHEL).
FreeIPA использует клиент-серверную модель. Клиентом может быть любая Linux машина, которая настроена для взаимодействия с FreeIPA (IdM) контроллером домена. Клиент осуществляет взаимодействие с помощью Kerberos, NTP, DNS сервисов и сертификатов.
Как настроить решение с репликацией из двух FreeIPA серверов с DNS можно почитать в этой статье, а для установки FreeIPA клиентов нам понадобится:
● Функционирующий FreeIPA контроллер с настроенным DNS сервером
● Один CentOS 7 сервер по крайней мере с 1GB памяти.
● Ansible version: 2.8+
● Terraform version: 0.13+
Конечно, можно устанавливать FreeIPA клиентов вручную. Это можно сделать в 3 шага:
1) Установить пакет yum install ipa-client
2) Запустить скрипт установки ipa-client-install
3) Пройти по шагам, ответив на вопросы установщика.
Но я уверен, что все прекрасно понимают плюсы автоматизации, поэтому мы пойдем немного другим путём. В Altenar мы используем два основных инструмента автоматизации ─ Ansible и Terraform. В данному случае мы решили использовать Ansible и взяли роль из официального репозитория freeipa.org с минимальным набором переменных в дополнение к перечисленным в /ipaclient/defaults/main.yml.
Playbook для запуска роли выглядит так:
Изначально мы также использовали ansible для создания DNS записей.
При этом возникала проблема: чтобы создать dns запись необходимо было сначала явно указать IP адрес «<
И так как мы используем в том числе Terraform в нашем частном облаке и стараемся придерживаться подхода IaC был найден terraform-provider-freeipa, который позволил нам добавлять DNS записи при создании виртуальных машин.
В результате мы получаем готовую DNS запись при создании виртуальной машины.
И ничто нам не мешает продолжить установку FreeIPA клиента с помощью Ansible роли.
Так выглядит процесс создания DNS записей и установки FreeIPA клиентов у нас в Altenar. Надеюсь, что наш опыт был вам полезен, ну а мы в свою очередь продолжим делиться лайфхаками.
Источник
Централизованное управление учетными записями на серверах
Добрый день, прошу совета.
Есть сервера, сейчас на них имеется около 60 учетных записей на каждом. Сейчас для создания пользователей используется Bash скрпт, но иногда возникают проблемы с разыми UID на серверах и куча всего еще.
Выразите пожалуйста ваши предложения, может использовать LDAP как в AD? Или хрень? Есть еще какие то предложения?
Выразите пожалуйста ваши предложения, может использовать LDAP как в AD? Или хрень? Есть еще какие то предложения?
Вы, собственно говоря, сами ответили на свой вопрос ;). LDAP как раз и предназначен для таких вещей. Как вариант, можно и полноценный AD развернуть на базе Samba4, если потом планируется те же учетные записи использовать на машинах с Windows. Ну и просто для полноты картины, NIS+ от Sun. Но это скорее историческую ценность имеет, сейчас неактуально.
Посмотрел несколько продуктов, такие как Samba4, OpenLDAP, FreeIPA, смотрел демки, функционала там слишком много, нет ли чего по проще?
Основная задача, давать пользователям доступ к SSH на сервере и обределенные права для групп и все.
это задача именно для OpenLDAP.
Если есть AD, используй AD. Если есть ldap, используй ldap. Ничего нет, бери freeipa.
Сервера подключать по realmd.
AD нет, это сервера в датацентре. А доступы по SSH нужны разработчикам, надоело скриптом создавать пользователей по отдельности на каждом сервере.
Тогда бери freeipa и не парь мозг. Можешь, конечно, взять голый openldap, но потом тебе захочется керберос аутентификацию, rbac и прочие фишечки freeipa. И ты постепенно превратишь openldap во freeipa на коленке, что, конечно, увлекательно и познавательно, но выйдет криво и бессмысленно.
Тебе не нужен LDAP. Реально, не твой масштаб. Напиши примитивный ansible-playbook и получи результат за пол процента от времени, потребного на возню с LDAP.
Я счас такую хрень велосипежу. 🙂 Как NIS, только поновее и менее замороченной в настройке. Через полгодика думаю уже будет на что посмотреть, но дедлайн «хоть что-то рабочее» — к началу января.
Если у тебя вся проблема в том, что ты создаешь учетки руками на серверах, то взял бы просто ansible, через него можно удобно рулить учетками на серверах. А по времени написать плейбук и завернуть туда пользователей — 1 час, при условии, что ты даже не видел ансибл никогда.
Составь формальный план учётных записей и используй какой-нибудь ansible
NIS/YP + kerberos. Заодно и хоумы можно будет по NFS.
Было бы круто потом посмотреть, что вышло ))) Если не забудешь, напиши плиз, СПАСИБО.
Перестать править конфиги ручками и ввести репозитарий конфигов/разработки, откуда лить все через оркестрацию. 60 ссш учеток — проходной дом.
С Ansible никогда не работал, но слышал. Не могли бы посоветовать или дать наводку, где с этим можно более подробно разобраться?
Полностью согласен, но разработчикам доступ нужен для запуска кронов, правки конфигов и прочее. Поэтому ищу такое решение которое упростит задачу в разы.
NIS/YP + kerberos. Заодно и хоумы можно будет по NFS.
Я такую схему (правда, без kerberos) применял в далеком 1999 г. Но советовать NIS в 2017. Сейчас, после появления Samba4, гораздо логичнее строить все на AD. Очень простое управление, гибкие настройки. Плюс в качестве бонуса прозрачная интеграция в сеть Windows-машин.
Заодно и хоумы можно будет по NFS.
Это можно делать при любой схеме авторизации — хоть NIS, хоть LDAP, хоть AD. Другой вопрос, что автору темы это ненужно ;).
А что плохого в kerberized NIS? Уж всяко проще и вменяемее самбы.
Есть ещё некий «облачный» userify.
И чем же проще? Как минимум, масштабируются любые LDAP-схемы (в том числе Samba) лучше, чем NIS. В частности, в отличие от LDAP, NIS поддерживает только плоские (одноуровневые) конфигурации, нет иерархии поддоменов. Все машины должны иметь одинаковую конфигурацию. Сравните с LDAP, где вы можете для любой машины задать свои собственные параметры. Нагрузка на сеть — копирование NIS-карт на все машины при любом редактировании.
В общем, всерьез обсуждать в 2017(!) году NIS как альтернативу LDAP, IMHO, все равно, что вместо SMTP рассматривать UUCP в качестве основного почтового протокола. Такой же анахронизм.
Не надо про 2017 — сейчас модно сидеть в вконтактике и ничего не знать. В конфигурации ТС даже обычный NIS всё потянет не напрягаясь. А kerberized NIS по гибкости вряд ли уступит LDAP. А рулить LDAP современные мозги не могут — ломаются быстро. А NIS + krb — 5 минут и готово. А с OU и полчими DN пущай kerberos мучается. А наша картинка ровная и красивая.
ansible прямой как полено, на уровне «взять описание серверов, групп и пользователей из файла, создать означенных пользователей на тех серверах» можно разобраться за пару часов.
В конфигурации ТС даже обычный NIS всё потянет не напрягаясь.
Согласен, потянет. Правда, только при одном условии — все серверы одинаковы. А если это не так? Если на разные серверы надо разных пользователей пускать? Ну и кто знает, через какое-то время потребуется масштабирование и что дальше? Все сначала переделывать?
А kerberized NIS по гибкости вряд ли уступит LDAP.
И каким же образом kerberos гибкости добавляет? Проблемы защиты, да, решает. Но гибкость-то откуда? Я бы еще понял, если бы Вы про NIS+ писали, хотя и там до LDAP по гибкости далеко.
А рулить LDAP современные мозги не могут — ломаются быстро.
Не стоит обобщать ;). А если серьезно, Вам просто не попадались хорошие учебники по LDAP — там все далеко не так сложно, как кажется на первый взгляд.
По той же Samba, например, отличная документация имеется. Разобраться там с нуля несложно.
Правда, только при одном условии — все серверы одинаковы.
Да и не надо преуменьшать гибкость NIS — стоит таки почитать.
Для централизованного управления доступом по ssh достаточно openldap без всего.
Если смущает ldap сложностью, можно использовать mysql в качестве источника данных о пользователях.
ОК, идея хорошая, но самому писать скрипты и прочее, это простите хрень.
Есть ли какие то уже готовые централизованные, быстро масштабируемые решения?
Домены — это NIS+ ;). В NIS никаких доменов не было.
Да и не надо преуменьшать гибкость NIS — стоит таки почитать.
Я в свое время активно пользовался этой технологией, так что знаю, о чем говорю ;). Просто всему свое время — то, что отлично работало в 90-х годах, сейчас выглядит анахронизмом ;).
Определитесь с целью, потом ищите иструменты.
Инструментов полно, но
функционала там слишком много, нет ли чего по проще?
вас же это не устраивает.
Поэтому ищу такое решение которое упростит задачу в разы.
Именно про это и разговор. Поправить job/playbook в гите или идти и править на сервере.
Заодно и история правок есть, и понятный конечный конфиг сервера. А не сборная солянка, в которой непонятно какие версии какого конфига сейчас находятся.
Поэтому ищу такое решение которое упростит задачу в разы.
Какую задачу, создать пользователей на N серверах?
username=«$1»
password=«$2»
for server in `cat ./server.list`
do
ssh you@$server useradd $1
ssh you@$server passwd $1 $2
done
Нужно еще проще?
Как же в NIS без доменов? Там всё есть. А анахронизмом выглядит потому, что не переусложнённое ушибленное на всю голову asn.1 непотребство.
Как же в NIS без доменов? Там всё есть.
Прошу прощения, неудачно выразился — имел ввиду иерархию поддоменов, как в DNS. Такого в NIS нет. А то, о чем Вы говорите, проблемы не решает — фактически, 2 домена NIS являются полностью изолированными со своими настройками. Т. е. если Вам надо, чтобы 20 пользователей имели доступ на все серверы, а еще по 10 пользователей были бы на каждом сервере уникальными, то средствами NIS Вы эту проблему не решите — уникальных пользователей придется добавлять отдельно на каждый сервер. Я уж не говорю про более сложные конфигурации, когда серверы объединяются в группы.
Нормальная иерархия доменов появилась только в NIS+, но это уже совсем другая история.
А анахронизмом выглядит потому, что не переусложнённое ушибленное на всю голову asn.1 непотребство.
В свое время это было очень продвинутое решение.
Вы не поняли, имелось в виду проще в использовании, а не проще в написании.
Для того, чтобы просто использовать инструменты, надо их внедрять.
Поддержка этих инструментов это не такое простое использование, как может показаться, что противоречит условию «просто использовать».
Использовать вышеуказанный скрипт для создания пользователей на нескольких серверах предельно просто, проще просто некуда. Но на самом деле это идиотизм, что я и пытаюсь донести до автора.
Собственно, я потому и ратую за ansible, что затраты на внедрять/поддерживать для него минимальные. При всех прочих недостатках это перевешивает.
что затраты на внедрять/поддерживать для него минимальные.
По сравнению с чем, по сравнению со скриптом выше? 🙂
Собственно, я потому и ратую за ansible, что затраты на внедрять/поддерживать для него минимальные.
А чтобы пользователю сменить себе пароль, надо плейбук отредактировать?
По сравнению с чем, по сравнению со скриптом выше? 🙂
А Вы допишите скрипт до вменяемого состояния, и увидете насколько он разрастётся и сколько с ним возни.
Никто не хранит пароли в текстовом виде. Для этого есть Ansible vault.
FreeIPA уже советовали?
Никто не хранит пароли в текстовом виде.
Пароль, хэш, vault — какая разница? Для того, чтобы сменить пароль пользователю надо обратиться к администратору?
Пароль нельзя хранить в репозитории, а vault — можно.
Для того, чтобы сменить пароль пользователю надо обратиться к администратору?
В таком случае «затраты на внедрять/поддерживать для него» отнюдь не минимальные. А если пользователей много, то близки к неприемлемым.
А удобство, как пользователей, так и администратора, и близко не сопоставимо с freeipa.
Мы всё ещё обсуждаем вопрос автора о создании/удаленнии пользователей для шести десятков программистов на нескольких серверах или плавно и незаметно перешли к вопросу управления персоналом мегакорпорации с десятком географически распределённых филиалов?
P.S. Уточню, я ни в коем случае не против ldap. Хорошая вещь на своём месте. Но чтобы выгоды от её использования начали превышать затраты от её использования нужно перерасти некоторый предел. Автор, вот, ещё не перерос.
Мы всё ещё обсуждаем вопрос автора о создании/удаленнии пользователей для шести десятков программистов на нескольких серверах
Да. В мегакорпорации управлять учётками ансиблом просто не получится.
60 пользователей уже не так уж мало. Конечно, если они аморфные существа, далёкие от компов и им дали логин/пароль, они его наклеили на монитор и относятся к нему как к неприкасаемому сакральному знанию, то проблем с ансиблом не будет.
Но я так понял, речь идёт о разработчиках. А значит это люди, которым может многое понадобится, включая разграничение доступа, снапшоты серверов, смена паролей и ещё куча всего непредсказуемого. И делать это всё админу руками (ансиблом) не имеет смысла, т.к. в ipa это всё может делаться вообще без участия админа. Мне бы было стыдно предлагать пользователям такое решение.
А главное, что 60 быстро вырастет до 100, а кол-во серверов до небес, и придётся переделывать.
Freeipa разворачивается просто, по-крайней мере, если речь о запросах ТС’а. Управление учётками и серверами тоже ничего сложного не представляет.
ИМХО, лучше сразу брать правильное решение, чем наворачивать костылей.
Но чтобы выгоды от её использования начали превышать затраты от её использования нужно перерасти некоторый предел. Автор, вот, ещё не перерос.
Удобство LDAP проявляется уже на десятке машин и пользователей. Предел, если он и есть, находится на уровне 2-3 компьютеров, IMHO.
Ну и не забывайте о масштабировании — где сегодня 60 разработчиков и 20 серверов, завтра легко может оказаться сотня народу на полсотни машин.
Источник
