управление пользователями

[Timur Batyrshin]

Всем привет!

Не по теме немного вопрос, но близко.

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

Мне известны только пара вариантов:

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

* поднимаем LDAP сервер, ставим phpldapadmin и ставим пересобранный SSH-сервер с поддержкой передачи ключей из LDAP -- это очевидно неудобно тем, что нужно пересобирать ssh, а также тем, что интерфейс phpldapadmin мягко говоря далек от совершенства.

Больше никаких вариантов не появилось за последнее время?

[Slawa Olhovchenkov]

Не появилось.
Но и более старые никуда не исчезли.

[Alexey Kralin]

Кажется вы хотите хранить пользователей в LDAP-е, извлекая их оттуда для скармливания "конфигурялке"?

Sincerely yours,
Alexey Kralin.

--
Вы получили это сообщение, поскольку подписаны на группу "devopsru".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Timur Batyrshin]

У более старых проблемы/неудобства, о которых я написал выше.

Все живут с этим или все же есть менее неудобные варианты?

вторник, 14 октября 2014 г., 15:25:24 UTC+4 пользователь Slawa Olhovchenkov написал:

[Timur Batyrshin]

Нет, смысла вытаскивать пользователей из LDAPа с тем, чтобы подсовывать их шефу мало.

вторник, 14 октября 2014 г., 20:45:56 UTC+4 пользователь Alexey Kralin написал:

[Timur Batyrshin]

В каком смысле? Я перечислил "более старые" варианты, которые мне пришли в голову.

Какие еще?

2014-10-14 21:06 GMT+04:00 Slawa Olhovchenkov <s...@zxy.spb.ru>:

On Tue, Oct 14, 2014 at 10:03:45AM -0700, Timur Batyrshin wrote:

> У более старых проблемы/неудобства, о которых я написал выше.

ась? более старые как-то тут вообще не рассмотрены.

[Slawa Olhovchenkov]

On Tue, Oct 14, 2014 at 09:15:27PM +0400, Timur Batyrshin wrote:

> В каком смысле? Я перечислил "более старые" варианты, которые мне пришли в
> голову.
> Какие еще?

kerberos, например.

> --
> Вы получили это сообщение, поскольку подписаны на группу devopsru.
>
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.

> Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Slawa Olhovchenkov]

On Tue, Oct 14, 2014 at 09:16:23PM +0400, Timur Batyrshin wrote:

> Ответ лучше не директом мне писать, а в гуглогруппу.

вот шит, настройки группы что ли поменялися?
раньше ответ в неё и шел.

PS: топ-квотинг -- зло.

> 2014-10-14 21:06 GMT+04:00 Slawa Olhovchenkov <s...@zxy.spb.ru>:
>
> > On Tue, Oct 14, 2014 at 10:03:45AM -0700, Timur Batyrshin wrote:
> >

> > > У более старых проблемы/неудобства, о которых я написал выше.
> >

> > ась? более старые как-то тут вообще не рассмотрены.
> >

[Timur Batyrshin]

А какая у него морда и как через него распространять SSH ключи?

вторник, 14 октября 2014 г., 21:17:32 UTC+4 пользователь Slawa Olhovchenkov написал:

[Slawa Olhovchenkov]

On Tue, Oct 14, 2014 at 10:55:18AM -0700, Timur Batyrshin wrote:

> А какая у него морда и как через него распространять SSH ключи?

зачем бы при керберосе ssh ключи?

> вторник, 14 октября 2014 г., 21:17:32 UTC+4 пользователь Slawa Olhovchenkov
> написал:
> >
> > On Tue, Oct 14, 2014 at 09:15:27PM +0400, Timur Batyrshin wrote:
> >
> > > В каком смысле? Я перечислил "более старые" варианты, которые мне пришли
> > в
> > > голову.
> > > Какие еще?
> >
> > kerberos, например.
> >
> > > 2014-10-14 21:06 GMT+04:00 Slawa Olhovchenkov <s...@zxy.spb.ru

> > <javascript:>>:

> > devopsru+u...@googlegroups.com <javascript:>.

[Alexander Driantsov]

Привет,

Не совсем понял про "не решает проблему авторизации во всяких мониторингах, логовницах и т.п.", а как они туда заходят? По SSH - те же ключи, через Web - oauth2 ... ?

Chef дете бэги прекрасно подходят для хранения публичные ключей, флагах доступа к репам и т.п. вещам. 

А чтобы всех юзеров по 100 раз на дню не раскатывать на новых инстансах - базовый образ, периодически пересобираемый

LDAP это круто, мощно, величественно... Но это еще одна сущность которую вам же поддерживать и чинить в случае чего. 

--

Вы получили это сообщение, поскольку подписаны на группу "devopsru".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.

[Timur Batyrshin]

Мысль понял, спасибо.

Поддерживать еще один сложный компонент для решения элементарных в общем-то задач желания нет.

вторник, 14 октября 2014 г., 22:37:38 UTC+4 пользователь Slawa Olhovchenkov написал:

[Slawa Olhovchenkov]

On Tue, Oct 14, 2014 at 11:55:39AM -0700, Timur Batyrshin wrote:

> Мысль понял, спасибо.
> Поддерживать еще один сложный компонент для решения элементарных в общем-то
> задач желания нет.

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

[Timur Batyrshin]

По HTTP.

Навскидку: Jenkins, Nagios, графики, логовница, JIRA (если используем локальную), Sonar (если у нас Java), RunDeck какой-нибудь.

С OAuth идея замечательная, попробую.

Он далеко не всем софтом поддерживается, но для большинства приложений скорее всего есть плагины.
Групп тоже, как понимаю, не будет, но на 2-3 десятка пользователей группы можно будет и вручную раздать.

И databagи шефа в этом случае не будут повторением данных.

Да, спасибо за совет!

вторник, 14 октября 2014 г., 22:46:42 UTC+4 пользователь Alexander Driantsov написал:

[Timur Batyrshin]

> да я бы не сказал что он сложный.
> и уж всяко проще чем проблемы с добавлением/убиранием ключей.
> ну и вообще, многие сервисы таки керборизированны, т.е. подходить он
> будет и для веба и для imapа. и для логина на всякие железки.

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

Вы получили это сообщение, так как подписаны на группу "devopsru".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/devopsru/izoDwFIqPp4/unsubscribe.
Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.

[Slawa Olhovchenkov]

On Tue, Oct 14, 2014 at 11:09:47PM +0400, Timur Batyrshin wrote:

> > да я бы не сказал что он сложный.
> > и уж всяко проще чем проблемы с добавлением/убиранием ключей.
> > ну и вообще, многие сервисы таки керборизированны, т.е. подходить он
> > будет и для веба и для imapа. и для логина на всякие железки.
>
> Судя по тому, что он сильно зависит от DNS и системного времени, подозреваю
> что мне только и придется делать что выяснять почему какой-нибудь менеджер
> на другом конце земли из местного кафетерия не может зайти графики
> посмотреть.

а у тебя управление идет кафетериями на другом конце земли?
потому как зависимость от времени и dns -- только между серверами,
комп с которого заходишь в этом учавствовать не обязан.

а не блюсти dns и время на своих серверах -- это себя очень не любить надо.

[Alexander Driantsov]

Тимур, 

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

Вы интересовались вариантами, так народ их накидал, как вы и просили. 

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

[Timur Batyrshin]

среда, 15 октября 2014 г., 0:17:44 UTC+4 пользователь Alexander Driantsov написал:

Очевидно, что при добавлении любого дополнительного сервиса от которого у вас зависит работа ваших сотрудников, у вас появляется еще одна точка отказа, которую вам нужно поддерживать, следить за патчами безопасности и вообще вникать в то как это конфигурить.

Да, и именно поэтому мне не нравится вариант LDAP с пропатченным SSH.

 

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

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

На нынешнем проекте пока вообще никакого разумного решения, потому и озадачился вопросом =) 

Вы интересовались вариантами, так народ их накидал, как вы и просили.

 Да, всем спасибо. Подумать есть над чем.

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

 Проблемы со своими вариантами я озвучил. OAuth и Kerberos возможно все их решат -- посмотрю на них.

[Kirill 8ll Sotnikov]

Еще есть вот такое https://wiki.debian.org/LDAP/NSS

Плюс для администрирования LDAP есть более приятная gosa https://oss.gonicus.de/labs/gosa/

[Timur Batyrshin]

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

Однако проблему распространения SSH ключей он никак не решает.

Чтобы gosa работала, нужно кучу каких-то кастомных схем в базу заливать, чего делать не очень то хочется.

вторник, 14 апреля 2015 г., 21:21:34 UTC+3 пользователь Kirill 8ll Sotnikov написал:

[Alexander Zhuravlev]

On Tue, Apr 14, 2015 at 02:01:51PM -0700, Timur Batyrshin wrote:
> NSS -- это стандартный способ маппинга пользователей во всех дистрибутивах,
> LDAP именно через него к системе и подключается.
> Однако проблему распространения SSH ключей он никак не решает.

Эта проблема тоже решается:
http://www.sysadmin.org.au/index.php/2012/12/authorizedkeyscommand/

На CentOS всё настраивается через sssd:
http://iomeweekly.blogspot.ru/2014/05/setup-ldap-authentication-on-centos-6.html
и AuthorizedKeysCommand в SSH.

>
> Чтобы gosa работала, нужно кучу каких-то кастомных схем в базу заливать,
> чего делать не очень то хочется.
>
> вторник, 14 апреля 2015 г., 21:21:34 UTC+3 пользователь Kirill 8ll Sotnikov
> написал:
> >
> > Еще есть вот такое https://wiki.debian.org/LDAP/NSS

> > <https://www.google.com/url?q=https%3A%2F%2Fwiki.debian.org%2FLDAP%2FNSS&sa=D&sntz=1&usg=AFQjCNGPqC6ar3Eki0vkfIc6sKzKDrbPpQ>

> >
> > Плюс для администрирования LDAP есть более приятная gosa
> > https://oss.gonicus.de/labs/gosa/
> >
> > On Tuesday, October 14, 2014 at 1:15:04 PM UTC+4, Timur Batyrshin wrote:
> >>
> >> Всем привет!
> >>
> >>
> >> Не по теме немного вопрос, но близко.
> >>
> >> Что вы используете для управления пользователями и их группами?
> >>
> >> Мне известны только пара вариантов:
> >> * создаем пользователей и раскладываем им SSH-ключи конфигурялкой -- это
> >> очевидно малоудобно для большого числа пользователей и не решает проблему
> >> авторизации во всяких мониторингах, логовницах и т.п.
> >> * поднимаем LDAP сервер, ставим phpldapadmin и ставим пересобранный
> >> SSH-сервер с поддержкой передачи ключей из LDAP -- это очевидно неудобно
> >> тем, что нужно пересобирать ssh, а также тем, что интерфейс phpldapadmin
> >> мягко говоря далек от совершенства.
> >>
> >> Больше никаких вариантов не появилось за последнее время?
> >>
> >>
>

> --
> Вы получили это сообщение, поскольку подписаны на группу devopsru.
>
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.
> Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--

Alexander Zhuravlev

[Timur Batyrshin]

В ubuntu 12.04 по-моему, нет ничего этого.

Спасибо, посмотрю, когда очередной подход буду делать.

Вы получили это сообщение, так как подписаны на группу "devopsru".

Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/devopsru/izoDwFIqPp4/unsubscribe.

Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.

[Ilya Zharskiy]

вторник, 14 октября 2014 г., 12:15:04 UTC+3 пользователь Timur Batyrshin написал:

Всем привет!

Не по теме немного вопрос, но близко.

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

 

Больше никаких вариантов не появилось за последнее время?

Последнее время вроде модно Single Sign-on (SSO). По реализациям не подскажу, выбирайте сами: https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations