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?

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.


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
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.