Безусловно, данная статья не является исчерпывающих руководством. Тем не менее, для наглядности рассмотрим классический пример админского доступа к серверам, в котором у каждого админа есть свой приватный ключ и прямой доступ на любой подконтрольный ему сервер:  У такого подхода есть определённые недостатки: Для сравнения рассмотрим доступ с условным администратором инфраструктуры в виде доменной группы:  Данный подход называют по разному, но так или иначе он уже давно существует в интегрированных коммерческих решениях. Обычно это реализовано через некую доменную группу привилегированных пользователей, которая имеет доступ ко всем или части систем инфраструктуры. У такого подхода есть некоторые (2, 3 и 5) недостатки предыдущего плюс очевидный нюанс — необходимость в постоянной доступности сервисов аутентификации и авторизации (конечно, не без кэширования). К слову, не составляет большого труда организовать нечто подобное с помощью PAM и LDAP. Итак, мы быстро подобрались к сути реализованной концепции доступа в cftotalcontrol:  По сути данный подход объединяет два предыдущих: Подразумевается, что инфраструктура построена на ранее рассмотренных модулях cfnetwork, cfauth и cfpuppetserver, но cftotalcontrol будет прекрасно жить без конфликтов и в смешанной среде. Во-первых, чтобы спать спокойно лучше всё же иметь хотя бы один SSH ключ, который будет прописан на всех системах через модуль cfauth, но который не будет использоваться для "бытовых" нужд. Разумеется, не стоит забывать про доступ к железу через IPMI и к виртуалкам через serial/GUI консоль на экстренный случай. Во-вторых, достаточно посмотреть на пример и: После этих нехитрых манипуляций, на узлах с классом cftotalcontrol будет создан пользователь cftcuser со специально заточенной средой Bash и конфигурацией SSH клиента. Настоятельно рекомендуется изменить имя пользователя на нестандартной через параметр cftotalcontrol::control_user. Все стандартные админские ключи из cfauth будут прописаны и данному пользователю, но для организации идеологически правильного доступа, админские ключи должны быть прописаны только в cftotalcontrol::ssh_auth_keys. Разумеется, сначала следует проверить, что всё работает и доступ есть ко всем серверам. В крупной инфраструктуре, практически всегда во внешний мир смотрит лишь малая часть систем и через них требуется организовать доступ к остальным системам. В SSH клиенте, это легко реализуется через опцию ProxyCommand со значением ssh -W target:port proxyhost. Такой подход более безопасен, чем использование SSH Agent Forwarding, позволяющего утащить приватный ключ админа на удалённой системе. В принципе, знание этих технических деталей необязательно для использование модуля cftotalcontrol, т.к. вся необходимая конфигурация генерируется на основе параметра cftotalcontrol::pool_proxy. Разумеется, перечисление прокси-узла для каждого целевого узла не только не эффективно, но и обязательно ведёт к частым ошибкам при добавлении новых систем. Вместо этого, для "навигации" используются факты cf_location и cf_location_pool, описанные в предыдущих частях. Обычно эти факты задаются при изначальной установке скриптом инициализации клиента cf_gen_puppet_client_init, но могут быть изменены через параметры модуля cfsystem. При генерации конфига SSH клиента, прокси узлы ищутся в следующем порядке: Разумеется, всё это дело интегрировано с cfnetwork и без лишних телодвижений добавляет всё, что нужно в конфигурацию сетевого фильтра. Обычно, специфичные однотипные задачи требуется запустить только на узлах с определёнными признаками (ОС, набор сервисов, роль и т.п.). Чтобы не городить свой огород по сегрегации узлов, это легко сделать через параметр cftotalcontrol::host_groups, который представляет собой ассоциативный массив, где ключ — это название группы, а значение может быть жёстко заданным списком узлом или строкой в виде запроса Puppet DB, о котором есть возможность почитать в описании модуля puppetdbquery. Пример: Должно быть понятно без лишних объяснений: Вот тут и начинается виртуальный пост админа. При первом заходе, система любезно предложит сгенерировать приватный ключ, а при последующих запустит SSH Agent и добавит в него приватный ключ, попутно спрашивая его пароль. А вот чтобы жизнь не казалась мёдом, система будет напоминать о необходимости обновить приватный ключ, если он старше cftotalcontrol::ssh_old_key_days = 180 дней. Если даже не заходить, то же самое будет делать cron, гневно высылая ежедневные письма. Сгенерировать новый ключ можно командой cftc_gen_key, которая ещё и автоматически установит его на всех контролируемых узлах, не требуя иных действий. Если что-то идёт не так, то старый ключ всегда можно найти в каталоге ~/.ssh/ с расширением в виде UNIX timestamp в секундах на момент генерации нового ключа. Такое может произойти из-за ошибки соединения, конфигурации Puppet или банального offline контролируемой системы. Вообще, под капотом творится следующее: Служебные команды Bash среды: Непосредственно работа с узлами: Значимые переменные среды: Стандартные команды — те же, что и добавлены в cfauth для вызова через sudo без пароля: Рано или поздно, определённые админские полномочия требуется давать людям. чьей зоной ответственности не является администрирование всей инфраструктуры. В число таких входят DevOps, DBA, Release Manager и прочие. Некоторые средства кластеризации также полагаются на SSH доступ к узлам-собратьям, который удобно настроить этим же модулем, включая автоматическую генерацию приватного ключа без пароля. Если коротко, то стандартный путь создания непривилегированных админов лежит через параметр cftotalcontrol::extra_users, который правильно создаёт ресурсы типа cftotalcontrol::admin. Особые отличия от пользователя "тотального" управления: Остаётся только вопрос как обозначить целевой узел. Это делается через параметр cftotalcontrol::auth::control_scope. На один и тот же узел можно повесить сразу несколько сфер. Пример: Обычно инициализируется через cftotalcontrol::extra_users. Все параметры такие же, как у cftotalcontrol, за исключением самого extra_users. Свободный художник на все руки