¿Cuál es el estado actual de la gestión de usuarios con Ansible?

He estado usando Ansible, con gran éxito, durante ~ 3 años para administrar una bandada cada vez mayor de sistemas Linux. Antes de sumergirme en mi pregunta, necesito establecer un contexto.

Como parte de mi trabajo diario, hago diseño, implementación y mantenimiento de sistemas para varias compañías que operan bajo el paraguas de una sola empresa de riesgo / incubadora. Existe una gran cantidad de polinización cruzada entre las compañías de nuestra cartera y, como tal, no podemos decir que solo los usuarios A, B y C necesitarán acceso a los sistemas de la compañía X. También pueden necesitar acceso a los sistemas Y de la compañía. Esto se complica por el hecho de que el entorno ansible de cada empresa vive en un repositorio git diferente. Esto significa que existe una gran cantidad de duplicación de código para implementar usuarios en los sistemas de diferentes compañías. Termino copiando / pegando bloques de código como este para implementar usuarios en los sistemas de una determinada empresa:

- 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

Esto funcionó bien cuando tenía que administrar a <5 usuarios, pero a medida que crece la base de usuarios, se vuelve cada vez más oneroso mantener las cosas actualizadas con la rotación de claves, nuevas contraseñas, etc.

Con la historia de fondo y el contexto establecidos, con mi pregunta:

Suponiendo que usar un sistema de autenticación centralizado (LDAP, etc.) no es una opción, ¿cómo podría abordar la creación de una base de datos de usuarios centralizada que puedan consumir varios libros de jugadas ansibles? Me encantaría poder mantener una lista central de usuarios, uids, hashes de contraseñas y claves públicas, y luego poder implementar los usuarios (con membresías de grupo personalizadas por host) en los hosts de cada empresa.

Estoy imaginando algún tipo de estructura de juego como:

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

... donde el uid, hash y clave pública de cada usuario se extraerían de la lista central y se desplegarían como de costumbre.

Entonces, ¿qué opciones tengo? He estado reflexionando sobre esto durante bastante tiempo y no he podido encontrar nada mejor que lo que ya estoy haciendo. ¿Podría hacer algo con un archivo de hechos personalizado para mantener mi base de datos de usuario?

Necesitas separar tus jugadas y tus datos.

Tengo un único repositorio con todos mis roles, hechos, etc. que se implementan en una amplia gama de sistemas de clientes. Me aseguro de que todos los roles sean valiosos y libres de datos. En host_vars/fqdn.ymlo group_vars/customer_name.ymldefino los datos que son únicos para ese cliente o sistema remoto.

La mayoría de mis roles se expanden con el tiempo según sea necesario y en lugar de hacer todo lo from roles/foo/main.ymlque tengo roles/foo/debian-foo.ymly roles/foo/openbsd-foo.ymleso solo se incluye cuando el sistema operativo u otra condición coincide.

Simplificado, roles/adduser/main.ymlpodría incluir esto:

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

y group_vars/ACME.ymlpodría incluir esto:

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

En su caso, puede estar bien tener entornos ansibles separados en cada uno de sus repositorios git, siempre que la carpeta de roles sea un submódulo compartido que sea idéntico en todos sus clientes.