Каково текущее состояние управления пользователями с Ansible?


10

Я с большим успехом использую Ansible ~ 3 года для управления постоянно растущим скоплением Linux-систем. Прежде чем погрузиться в мой вопрос, мне нужно установить контекст.

В рамках своей повседневной работы я занимаюсь проектированием, развертыванием и обслуживанием систем для различных компаний, которые работают под эгидой одной компании / инкубатора. Среди наших портфельных компаний много перекрестного опыления, и поэтому мы не можем сказать, что только пользователям A, B и C потребуется доступ к системам компании X. Им также может понадобиться доступ к системам компании Y. Это усложняется тем фактом, что каждая среда, в которой работает каждая компания, находится в другом репозитории git. Это означает, что существует много дублирования кода для развертывания пользователей в системах разных компаний. Я заканчиваю копировать / вставлять блоки кода, подобные этому, чтобы развернуть пользователей в системах определенной компании:

- name: add several users
  user: >
    name={{ item.name }}
    state=present
    groups={{ item.groups }}
    uid={{ item.uid }}
    password={{ item.password }}
    shell=/bin/bash
  with_items:
    - { name: 'user1', groups: 'ssh-access,sudo', uid: '501', password: '<redacted>' }
    - { name: 'user2', groups: 'ssh-access,sudo', uid: '502', password: '<redacted>' }
  tags: users

- name: authorized_keys - user1 
  action: authorized_key user=user1 key="{{ lookup('file', 'pubkeys/user1') }}" manage_dir=yes
  tags:
    - pubkeys
    - users

- name: authorized_keys - user2 
  action: authorized_key user=user2 key="{{ lookup('file', 'pubkeys/user2') }}" manage_dir=yes
  tags:
    - pubkeys
    - users

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

С предысторией и контекстом, на мой вопрос:

Предполагая, что использование централизованной системы аутентификации (LDAP и т. Д.) Не является вариантом, как я могу заняться созданием централизованной базы данных пользователей, которую могут потреблять различные сборники игр? Мне бы хотелось иметь возможность поддерживать один центральный список пользователей, идентификаторов пользователей, хэшей паролей и открытых ключей, а затем иметь возможность развертывать пользователей (с настраиваемым членством в группах для каждого узла) на хостах каждой компании.

Я предполагаю какую-то игровую структуру вроде:

- name: Deploy users
  user_management:
    - { name: "user1", groups: "sudo" }
    - { name: "user1", groups: "sudo" }

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

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

Ответы:


8

Вы должны разделить ваши игры и ваши данные.

У меня есть одно репо со всеми моими ролями, фактами и т. Д., Которые используются в широком спектре систем клиентов. Я гарантирую, что все роли могут быть изменены и не содержат данных. В host_vars/fqdn.ymlили group_vars/customer_name.ymlя определяю данные, которые являются уникальными для этого клиента или удаленной системы.

Большинство моих ролей расширяются со временем по мере необходимости и вместо того, чтобы делать все, что у from roles/foo/main.ymlменя есть, roles/foo/debian-foo.ymlи roles/foo/openbsd-foo.ymlэто включается только тогда, когда ОС или другое условие совпадают.

Упрощенно, roles/adduser/main.ymlможет включать это:

- user: name={{ item.name }} ...
  with_items:
  - customer_users

и group_vars/ACME.ymlможет включать это:

customer_users:
- name: sausage
   uid: 32153
- name: beans
   uid: 1024

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


Это указывает мне в правильном направлении. Спасибо Алекс! Мне все еще нужно будет разобраться, как поддерживать единую базу данных имен пользователей / ключей / uids / и т. Д., На которую я могу ссылаться из различных ролей и / или групп, но я думаю, что у меня есть некоторые идеи о том, как я могу это сделать.
EEAA

1
@EEAA Помните, что role / all может быть каталогом с файлами, чтобы вы могли легко централизовать ролей / all / staff.yml, role / all / foo.yml и т. Д.
Alex Holst,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.