Qual è lo stato dell'arte attuale per la gestione degli utenti con Ansible?


10

Uso Ansible, con grande successo, da circa 3 anni ormai per gestire un gregge sempre crescente di sistemi Linux. Prima di immergermi nella mia domanda, devo impostare un contesto.

Come parte del mio lavoro quotidiano, eseguo progettazione, installazione e manutenzione di sistemi per varie aziende che operano tutte sotto l'egida di una singola impresa / incubatrice. Vi è molta impollinazione incrociata tra le società del nostro portafoglio e, come tale, non possiamo dire che solo gli utenti A, B e C avranno bisogno di accedere ai sistemi dell'azienda X. Potrebbero anche aver bisogno dell'accesso ai sistemi dell'azienda Y. Ciò è complicato dal fatto che l'ambiente di risposta di ciascuna azienda vive in un repository git diverso. Ciò significa che esiste molta duplicazione del codice per distribuire gli utenti ai sistemi di diverse società. Finisco per copiare / incollare blocchi di codice come questo in giro per distribuire gli utenti ai sistemi di una determinata azienda:

- 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

Funzionava bene quando avevo un <5 utenti da gestire, ma man mano che la base di utenti cresce, diventa sempre più oneroso aggiornare le cose con la rotazione dei tasti, nuove password, ecc.

Con il retroscena e il contesto impostato, con la mia domanda:

Supponendo che l'uso di un sistema di autenticazione centralizzato (LDAP, ecc.) Non sia un'opzione, come potrei affrontare la creazione di un database utente centralizzato che potrebbero essere utilizzati da vari playbook rispondibili? Mi piacerebbe poter mantenere un elenco centrale di utenti, uid, hash delle password e chiavi pubbliche, e quindi essere in grado di distribuire gli utenti (con appartenenze a gruppi per host personalizzati) agli host di ogni azienda.

Sto immaginando una sorta di struttura di gioco come:

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

... dove ogni utente, hash e chiave pubblica di ogni utente verrebbero estratti dall'elenco centrale e distribuiti come al solito.

Quindi, quali opzioni ho? Ci sto riflettendo da un po 'di tempo, e non sono stato in grado di trovare qualcosa di meglio di quello che sto già facendo. Posso fare qualcosa con un file dei fatti personalizzato per contenere il mio database utenti?

Risposte:


8

Devi separare i tuoi spettacoli e i tuoi dati.

Ho un unico repository con tutti i miei ruoli, fatti, ecc. Che si distribuiscono su una vasta gamma di sistemi di clienti. Garantisco che tutti i ruoli siano affidabili e privi di dati. In host_vars/fqdn.ymlo group_vars/customer_name.ymldefinisco i dati che sono unici per quel cliente o sistema remoto.

La maggior parte dei miei ruoli si espande nel tempo in base alle necessità e invece di fare tutto ciò from roles/foo/main.ymlche ho roles/foo/debian-foo.ymle roles/foo/openbsd-foo.ymlche sono inclusi solo quando il sistema operativo o un'altra condizione corrisponde.

Semplificato, roles/adduser/main.ymlpotrebbe includere questo:

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

e group_vars/ACME.ymlpotrebbe includere questo:

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

Nel tuo caso potrebbe essere OK avere ambienti rispondibili separati in ciascun repository git, purché la cartella dei ruoli sia un sottomodulo condiviso identico per tutti i tuoi clienti.


Questo mi indica la giusta direzione. Grazie Alex! Avrò ancora bisogno di capire come mantenere un unico database di nomi utente / chiavi / uidi / etc a cui posso fare riferimento da vari ruoli e / o gruppi, ma penso di avere alcune idee su come riuscirci.
SEE

1
@EEAA Ricorda che i ruoli / tutti possono essere una directory con file in modo da poter centralizzare facilmente i ruoli / all / staff.yml, ruoli / all / foo.yml, ecc.
Alex Holst,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.