Jaki jest obecny stan zarządzania użytkownikami w Ansible?

10

Od ok. 3 lat używam Ansible, z wielkim powodzeniem, do zarządzania stale rosnącym stadem systemów linuksowych. Zanim przejdę do pytania, muszę ustalić kontekst.

W ramach mojej codziennej pracy zajmuję się projektowaniem, wdrażaniem i konserwacją systemów dla różnych firm, które działają pod patronatem jednej firmy typu venture / inkubator. Nasze spółki portfelowe są bardzo zapylone i dlatego nie możemy powiedzieć, że tylko użytkownicy A, B i C będą potrzebować dostępu do systemów firmy X. Mogą także potrzebować dostępu do systemów firmy Y. Komplikuje to fakt, że środowisko ansible każdej firmy żyje w innym repozytorium git. Oznacza to, że przy wdrażaniu użytkowników w różnych systemach firmy występuje dużo duplikatów kodu. W rezultacie kopiuję / wklejam bloki kodu w taki sposób, aby wdrożyć użytkowników w systemach pewnej firmy:

- 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

Działało to OK, gdy miałem <5 użytkowników do zarządzania, ale wraz z powiększaniem się bazy użytkowników coraz trudniej jest aktualizować klucze, zmieniając hasła, nowe hasła itp.

Po ustawieniu historii i kontekstu, moje pytanie:

Zakładając, że korzystanie ze scentralizowanego systemu uwierzytelniania (LDAP itp.) Nie jest opcją, w jaki sposób mogę rozwiązać problem tworzenia scentralizowanej bazy danych użytkowników, z której mogłyby korzystać różne odpowiadające podręczniki? Chciałbym móc utrzymać jedną centralną listę użytkowników, identyfikatory użytkowników, skróty haseł i klucze publiczne, a następnie móc wdrożyć użytkowników (z niestandardowym członkostwem w grupie dla poszczególnych hostów) na hostach każdej firmy.

Przewiduję jakąś strukturę gry, taką jak:

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

... gdzie identyfikator użytkownika, skrót i klucz publiczny każdego użytkownika byłyby pobierane z centralnej listy i wdrażane jak zwykle.

Jakie mam opcje? Zastanawiam się nad tym od dłuższego czasu i nie byłem w stanie wymyślić nic lepszego niż to, co już robię. Czy mogę zrobić coś z niestandardowym plikiem faktów, aby przechowywać bazę danych użytkowników?

EEAA
źródło

Odpowiedzi:

8

Musisz oddzielić swoje gry i dane.

Mam pojedyncze repozytorium ze wszystkimi moimi rolami, faktami itp., Które są wdrażane w szerokiej gamie systemów klienckich. Zapewniam, że wszystkie role są możliwe do zmiany i wolne od danych. W host_vars/fqdn.ymllub group_vars/customer_name.ymldefiniuję dane, które są unikalne dla tego klienta lub systemu zdalnego.

Większość moich ról jest z czasem rozszerzana w miarę potrzeb i zamiast robić wszystko, from roles/foo/main.ymlco mam roles/foo/debian-foo.ymli roles/foo/openbsd-foo.ymlktóre są uwzględniane tylko wtedy, gdy system operacyjny lub inny warunek jest zgodny.

Uproszczony, roles/adduser/main.ymlmoże obejmować:

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

i group_vars/ACME.ymlmoże obejmować to:

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

W twoim przypadku może być OK posiadanie osobnych środowisk ansible w każdym repozytorium git, o ile folder ról jest współużytkowanym podmodułem, który jest identyczny dla wszystkich klientów.

Alex Holst
źródło
To wskazuje mi właściwy kierunek. Dzięki Alex! Nadal będę musiał ustalić, jak utrzymywać jedną bazę danych nazw użytkowników / kluczy / identyfikatorów użytkowników itp., Do której mogę odwoływać się z różnych ról i / lub grup, ale myślę, że mam pewne pomysły, jak to osiągnąć.
EEAA
1
@EEAA Pamiętaj, że role / all może być katalogiem z plikami, dzięki czemu możesz łatwo scentralizować role / all / staff.yml, role / all / foo.yml itp.
Alex Holst