Есть множественный ответы которые фактически говорят, что ldap следует использовать вместо марионетки для управления фактическими пользователями. Я склонен согласиться, исходя из перспективы масштабирования. Адаптация новых сотрудников должна производиться группами поддержки, а не системными администраторами, добавляющими новые пользовательские ресурсы.
Однако управление ключами ssh и авторизованными ключами (наряду с доступом sudo и файлами конфигурации пользователя) кажется идеальной задачей для марионетки.
Каков стандартный способ управления ключами и конфигурацией для каждого пользователя? Может ли марионетка здесь увеличивать ldap? Что произойдет, если сотрудник станет мошенником, и нам потребуется отозвать его ключ из 1000 различных файлов authorized_keys?
Я не согласен с Грейгом Ватсоном.
Создание копий учетных записей означает, что у вас возникнут проблемы с их синхронизацией. Наличие единого источника информации для аутентификации устраняет множество сложностей, а LDAP намного проще интегрировать в другие службы (Интернет, почта и т. Д.).
Что касается доступа sudo - если вы настраиваете свои sudoers на основе групп, а не отдельных лиц, то доступ к объектам можно легко контролировать через LDAP. Это требует более перспективного планирования - но им гораздо легче управлять в долгосрочной перспективе - вы управляете безопасностью политика не файлы данных.
Сделать ключи ssh доступными на других машинах лучше всего с помощью какой-либо сетевой файловой системы - это может быть NF / Samba, но репликация или общие файловые системы обеспечивают ту же цель (с разными побочными эффектами).
Первым шагом всегда должно быть определение вашей модели безопасности - разрешение локальных конфигураций дает огромные возможности для подрыва этой модели.
Я очень доволен: http://www.freeipa.org/page/Main_Page
Он содержит все, что вам нужно - пользователей, sudoers, ключи ssh, даже конфигурацию selinux.
На самом деле я бы сказал, что Puppet - лучшее решение, чем LDAP, поскольку у него нет SPoF (входы локальные, но управляются централизованно).
В любом случае, для вашего сценария «мошеннический пользователь» вы можете использовать ssh_authorized_key Марионеточный ресурс и ensure => absent на их ключе. Затем используйте Mcollective / cron, чтобы заполнить это.
См. Документ: http://docs.puppetlabs.com/references/latest/type.html#sshauthorizedkey
Сложность заключается в том, что Puppet управляет файлом в домашних каталогах пользователей (которые могут существовать, а могут и не существовать). Вы можете смягчить это, настроив расположение файла authorized_keys в своей конфигурации SSH (т.е. /var/lib/ssh/authorized_keys/%u).