Централизованное управление учетными записями на серверах

Но я так понял, речь идёт о разработчиках. А значит это люди, которым может многое понадобится, включая разграничение доступа

И делать это всё админу руками (ансиблом) не имеет смысла, т.к. в ipa это всё может делаться вообще без участия админа.

What? Пользователи сами себе будут группы доступа назначать? Что значит разграничение доступа без участия админа?

Вы с одной стороны правы, а с другой — нет. Т.е. можно совершить ошибку первого рода «сделать что-то из говна и палок, в режиме полтора пользователя два раза в день заходят это работает, в промышленной эксплуатации — нет». А можно и второго рода «убить кучу времени на построение мастабирумого отказоустойчивого хайлоад кластера с кучей девяток SLA когда высокая доступность нафиг никому не нужна, да и масштабируемость на стотыщ клиентов этой фирме в этом тысячелетии не грозит». И мне кажется Ваш совет ближе ко второй ситуации, нежели первой.

Вообще нашей профессии свойственно городить избыточную сложность там где этого можно избежать.

Если на разные серверы надо разных пользователей пускать?

Ты точно работал с NIS? Это элементарно делается нетгруппами (netgroups).

Главное достоинство NIS в том, что ее все умеют из коробки - AIX, Solaris, HP-UX...

NIS+ - слишком сложен. Кроме как на Солярке нигде ее не видел. В отличие от NIS, это трупик.

Если не нужна интеграция с AD и с IDM, то NIS+Kerberos - отличный вариант.

What? Пользователи сами себе будут группы доступа назначать? Что значит разграничение доступа без участия админа?

Есть ПМ или другое ответственное лицо, которое решает кому и куда выдавать доступ (в рамках ресурсов своего проекта). Для него создаются группы доступа и выдаются соответствующие права. По желанию рисуется отдельная веб-морда или используется морда freeipa.

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

Разумеется, если ему понадобится создать новую группу, он обращается к админу. Хотя и тут можно навертеть всякого, было бы желание.

До чего же некоторые любят усложнять :-(

Некоторые любят избавляться от лишней работы, и не делать руками то, что можно делать автоматизированно.

Поднять лдап, настроить везде авторизацию по лдапу, сделать специальную админку для этого хозяйства и объяснить всем как ей пользоваться — это называется «избавляться от лишней работы»?

Вспоминается анекдот:

Два друга встречаются:
— Я тут слышал, ты машину купил?
— Да! И как раньше жил! Теперь все успеваю! Вчера за день успел сменить масло, купить новые шины, съездил на авторынок за крыльями, тут же смотался в автосервис и поменял их, еще и в магазин за незамерзайкой заехал. И как бы я все это без машины успел?!

это очередной сказочник типа erzent, но этот хоть гуглить немного умеет.

Поднять лдап, настроить везде авторизацию по лдапу

Мы говорим про openldap и костыляние idm на коленке, или про freeipa?

Если про второе, то поднятие freeipa и заведение серверов в домен по затратам вполне сравнимо с аналогичными действиями для ansible. Конечно, ansible вещь полезная, и если он уже есть, то использовать его чуть проще. Но у тс'а его, я так понял, нет.

сделать специальную админку для этого хозяйства и объяснить всем как ей пользоваться — это называется «избавляться от лишней работы»?

Ну там написано: по-желанию. У меня такое желание скорее всего возникло бы, ибо написать админку, добавляющую пользователей в группы не сложно.

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

Ну и избавление от звонков позним вечером, с сообщением, что срочно нужен доступ всем и везде, потому что ..., это вообще бесценно.

Мы говорим про openldap и костыляние idm на коленке, или про freeipa?

Без разницы. Нам нужен плэйбук, чтобы поднять сервер-авторизатор и плэйбук, чтобы чтобы настроить авторизацию через этот сервер. И это уже сложнее, чем плэйбук, который безыдейно создаст нужных пользователей и группы.

Но у тс'а его, я так понял, нет.

У него есть автоматизация посредством bash-скриптов. Перейти на использование ansible/salt/puppet/whatever — правильное и своевременное решение.

Разумеется зависит от того, как часто вообще приходится менять что-либо.

Sic! Это же самое главное. Моя оценка для конторы с 60 программистов: раз в месяц приходит новый человек и раз в месяц (на самом деле реже) завершается проект/начинается проект, в общем, происходит какая-то организационная пертурбация.

Таким образом при использовании ansible мы решение вида «раз в две-три недели поправить текстовый файлик». Всё. Просто сделать. Просто сопровождать. И в этой схеме ломаться нечему.

Без разницы. Нам нужен плэйбук, чтобы поднять сервер-авторизатор и плэйбук, чтобы чтобы настроить авторизацию через этот сервер.

Если у тебя уже есть ансибл и ты с ним знаком, то да. Если нет, то поднять ансибл, чтобы поднять freeipa - это не очень разумно. Если собрался поднимать оба решения, то сделать сперва ансибл правильно. Но тс об ансибле и не задумывался, хотя возможно зря.

У него есть автоматизация посредством bash-скриптов. Перейти на использование ansible/salt/puppet/whatever — правильное и своевременное решение.

Перейти на ансибл в качестве idm - это в корне неверное решение, ибо вместо idm получаешь пачку костылей и позор, со стороны всех, кто хоть что-то в it понимает.

Sic! Это же самое главное. Моя оценка для конторы с 60 программистов: раз в месяц приходит новый человек и раз в месяц (на самом деле реже) завершается проект/начинается проект, в общем, происходит какая-то организационная пертурбация.

Я не говорил, что писать админку в ситуации ТС необходимо. Я говорил, что это возможно, и несложно. И что я бы, весьма вероятно, её сделал.

Таким образом при использовании ansible мы решение вида «раз в две-три недели поправить текстовый файлик».

Я не буду спорить с цифрами, ибо про уровень загрузки ТС'а мне ничего не известно.

Но таким образом, даже если исключить то, что можно передать администрирование групп пользователей в чужие руки, мы имеем:

ansible: для любого действия нужно обращаться к админу, править конфиг и перезаливать на сервера.

freeipa: создание учёток в руках админа, для добавления пользователя на какой-либо сервер достаточно включить его в группу, sso на халяву, гибкая система прав, пользователь может изменить свой пароль самостоятельно.

Затраты времени на настройку и сопровождение у них одного порядка. Наверное, ансибл интуитивно попроще. Но с точки зрения idm, freeipa намного удобнее.

Ты точно работал с NIS? Это элементарно делается нетгруппами (netgroups).

Угу, просто это очень давно было. Да и задачи у меня проще были - настройка одинаковых клиентов (рабочих мест) для пользователей.

Это элементарно делается нетгруппами (netgroups).

Да, тут Вы правы.

Главное достоинство NIS в том, что ее все умеют из коробки - AIX, Solaris, HP-UX...

Хм, тоже самое можно сказать и про любой (ok, почти любой) ldap ;). Да и сегодня сами эти системы экзотика, честно говоря ;).

Кроме как на Солярке нигде ее не видел.

Это да. А знаете, почему? Потому что появился ldap, IMHO. А ведь многие идеи у NIS+ и ldap схожи. Мне кажется, ldap вполне можно рассматривать как в некотором роде наследника идей, заложенных в NIS+ (иерархия доменов, деревообразная структура данных и др.).

В отличие от NIS, это трупик.

Честно говоря, сегодня они (NIS и NIS+) обе похожи на трупы ;).

Да, есть работающие инсталляции, есть даже средства интеграции с ldap-службами. Но разворачивать такие структуры с нуля сегодня большого смысла нет (IMHO).

А можно и второго рода «убить кучу времени на построение мастабирумого отказоустойчивого хайлоад кластера с кучей девяток SLA

По-моему, Вы сильно переоцениваете сложность развертывания инфраструктуры ldap ;).

Поднять лдап, настроить везде авторизацию по лдапу, сделать специальную админку для этого хозяйства и объяснить всем как ей пользоваться — это называется «избавляться от лишней работы»?

Почитав Вас, складывается ощущение, что реализаций ldap вообще нет - есть только описание протокола (rfc) ;). И несчастный админ должен долгими ночами писать и настраивать свою реализацию ;).

А если серьезно, то существует куча практически готовых к эксплуатации служб каталогов, основанных на ldap. Можно взять любой, адаптировать под свои задачи и наслаждаться жизнью ;).

маСтабируемо, стотЫщ - ***** много осень ного звеСть..

Если нет, то поднять ансибл, чтобы поднять freeipa - это не очень разумно.

В корне с этим не согласен. infrastructure as a code радикально снижает затраты на развёртывание и сопровождение сервисов. Поднять ансибл, чтобы поднять whatever — единственный разумный способ. Альтернатива ­— погрязнуть в трясине колхозного рукоблудия.

пользователь может изменить свой пароль самостоятельно.

Кстати, а почему Вы так настойчиво подчёркиваете этот пункт? Вы администрируете аквариум и золотые рыбки постоянно забывают пароль? Мне правда интересно какой жизненный опыт может заставить так расставлять приоритеты.

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

ldap-сервер — единая точка отказа для всей инфраструктуры, значит он должен быть продублирован. Два раза, чтобы избежать split-brain. А раз уж у нас есть три экземпляра, то перед ними можно поставить load balancer. Рядом — сервис мониторинга и оповещения, а для бэкапов прикупить стойку в другом датацентре. Потому что мы ответственные люди и всё делаем надёжно и правильно. Кстати, все сейчас делают мониторинг в прометее на микросервисах. Тоесть нам нужен kubernetes кластер. Так гугл делает, а мы чем хуже? Для бэкапов можно поднять ceph кластер (для любителей свободного програмного обеспечения) или купить СХД от NetApp'а (кому энтерпрайз по нраву).

Один человек, конечно, не потянет, а вот команда из трёх-четырёх человек + начальник — запросто. По завершению внедрения можно статью на хабре написать, на конференцию какую съездить, да и банально у начальство потребовать премию. Зря что-ли команда ночей не спала и месяцами вкалывала, должна же быть в этом мире справедливость? А админ, который за пол часа текстовый файлик сварганил чем может похвастаться, где его достижения, за что примию давать? Вот то-то.

Кстати, а почему Вы так настойчиво подчёркиваете этот пункт?

Да, в общем-то, никакого. Просто, если бы мне выдали логин/пароль, который можно поменять только у админа, я бы смотрел на этих людей, как на странно. И был бы в полной уверенности, что невероятных масштабов костыли в наличии. 21 век на дворе, а тут такое.

Ну, ок. Каждый имеет право на своё мнение, хотя бы и странное на мой взгляд.

Да, кстати, забыл написать, не факт, что в изначальной задаче вообще требуются пароли кому-нибудь.

Поздравляю, Вы только что в очередной раз доказали прописную истину - любую идею можно довести до маразма ;).

Единственное, в чем могу согласиться с Вами, так это в том, что исходная задача довольно проста и потенциально может быть решена разными методами. Бывают ситуации, когда действительно стоит в качестве критерия выбора использовать не только и даже не столько достоинства и недостатки самих технологий, сколько знакомство конкретного админа с ними. Хорошо знает NIS - пусть делает на NIS, хоть это и анахронизм, знаком с ldap - просто отлично ;). Ну а если проще с Ansible - почему нет?

Другой вопрос, что дьявол обычно кроется в деталях, которые нам с Вами неизвестны. Вот в результате и обсуждаем сферических коней в вакууме ;).

а ансибл значит не надо ни резервировать, ни бэкапы? ты ещё забыл, что лдап и базы должны быть в докере, хипстерок ты наш недоделанный, а что, все так делают.

Забыл добавить, — и всё это хозяйство конечно же в облаке.

Всем спасибо за советы и помощь, буду пробовать все предложенные варианты и выбирать более подходящий.

Всем доброго дня :-)