Який сучасний стан управління користувачами за допомогою Ansible?

Я з великим успіхом використовую 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, хеш та відкритий ключ кожного користувача будуть витягнуті з центрального списку та розгорнуті як завжди.

Отже, які у мене варіанти? Я досить довго роздумував над цим, і не зміг придумати нічого кращого, ніж те, що я вже роблю. Чи можу я щось зробити зі спеціальним файлом фактів для зберігання моєї бази даних користувачів?

Вам потрібно розділити свої відтворення та свої дані.

У мене є єдине репо з усіма моїми ролями, фактами тощо, які розгортаються для широкого кола клієнтських систем. Я переконуюсь, що всі ролі є доступними і без даних. В 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 repo було окреме середовище, яке відповідає, доки папка ролей - це спільний підмодуль, однаковий для всіх ваших клієнтів.