Ansible vs LDAP

топ 100 блогов klink0v30.01.2023

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


  1. Ansible / Salt / Puppet / Chef и прочие системы управления конфигурациями. Выделяем где-нибудь сервер, на нем описываем правила / политики / playbooks, туда же кладем открытые ключи. Пару раз в день по крону запускается некая "глобальная" playbook, которая приводит список пользователей и их привилегии в соответстии с желаемыми.
  2. LDAP. Вся инфа о пользователях хранится в единым каталоге, на который настроены остальные машины. Управление пользователями-правами-ключами осуществляется через этот каталог.

У каждого подхода есть свои достоинства и недостатки.

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

Из достоинств: удобно администрировать, легко вести логи / аудит любых изменений, всё находится в одном месте, пользователь на любой машине будет иметь один и тот же UID (иногда это бывает ценно), можно прикрутить прозрачный вход с GSSAPI и вообще отказаться от раскладывания SSH-ключей.

С Ansible ситуация обратная. Всё работает надёжно, т.к. все пользователи являются локальными. Но плейбуки и роли рано или поздно неизбежно превратятся в большую помойку, в которой невозможно что-нибудь понять, даже если админы супер-аккуратные. А если им присуще хотя бы лёгкое рас3.14здяйство и/или их больше двух, то момент превращения в помойку наступает очень быстро.

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

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

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

Оставить комментарий

Предыдущие записи блогера :
Архив записей в блогах:
мы с подружкой в кровь поссорились недавно. Она сказала, что я некачественно выполнила мою работу для нее. дело было в ретуши и во внешности. Она заказала фотки. Хочу как в глянце. Я сделала ей ретушь. Очень старалась, сохраняла текстуру кожи, теплый свет и цвет - все прям ваще - отдыхала ...
Начать с того, что в своё время роман мною был прочитан два раза точно, а некоторые моменты заучены чуть ли не наизусть. Так что не смотреть фильм было нельзя. А в продолжение ...
Продолжаем знакомиться с необычными достопримечательностями колоритного узбекского города Ташкента. И сегодня мы отправимся в центр торговой жизни города и осмотрим знаменитый базар Чорсу. Мы рассмотрим его архитектуру, прогуляемся по торговым рядам и узнаем, каковы туристические ...
Поскольку часто встречаю разные мнения на этот счет, решил собрать здесь основные свои знания по теме: 1. Раздача квартир в СССР осуществлялась очень неравномерно. Причем, практически всегда (начиная примерно с 70-х, раньше было по разному) можно было найти место, где квартиры давали ...
Про вчерашних победителей Меня часто спрашивают, что я думаю про подтвержденные или декларируемые результаты известных активных управляющих или спекулянтов? В России, например, иногда называют фамилии Элвиса Марламова, Олега Клоченка, Александра Силаева, компанию Арсагера и т.д. и т.п. ...