Qual é o estado da arte atual para gerenciamento de usuários com o Ansible?

Estou usando o Ansible, com grande sucesso, há cerca de 3 anos para gerenciar um bando de sistemas Linux cada vez maior. Antes de mergulhar na minha pergunta, preciso definir um contexto.

Como parte do meu trabalho diário, faço design, implantação e manutenção de sistemas para várias empresas que operam sob a égide de uma única empresa de empreendimento / incubadora. Há muita polinização cruzada entre as empresas de nosso portfólio e, como tal, não podemos dizer que apenas os usuários A, B e C precisarão acessar os sistemas da empresa X. Eles também podem precisar de acesso aos sistemas da empresa Y. Isso é complicado pelo fato de o ambiente ansável de cada empresa viver em um repositório git diferente. Isso significa que há muita duplicação de código para implantar usuários em sistemas diferentes da empresa. Acabo copiando / colando blocos de código como esse para implantar usuários nos sistemas de uma 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

Isso funcionou bem quando eu tinha <5 usuários para gerenciar, mas à medida que a base de usuários cresce, fica cada vez mais oneroso manter as coisas atualizadas com a rotação de teclas, novas senhas etc.

Com a história de fundo e o conjunto de contextos, continuo com a minha pergunta:

Supondo que o uso de um sistema de autenticação centralizado (LDAP, etc.) não seja uma opção, como eu poderia lidar com a criação de um banco de dados centralizado de usuários que vários manuais ansiosos poderiam consumir? Gostaria de poder manter uma lista central de usuários, uids, hashes de senha e chaves públicas e poder implantar os usuários (com associações personalizadas por grupo de hosts) nos hosts de cada empresa.

Estou visualizando algum tipo de estrutura de jogo como:

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

... em que o uid, o hash e a chave pública de cada usuário seriam retirados da lista central e implantados como de costume.

Então, quais opções eu tenho? Estou pensando nisso há um bom tempo e não consegui encontrar nada melhor do que o que já estou fazendo. Posso fazer algo com um arquivo de fatos personalizado para armazenar meu banco de dados de usuários?

Você precisa separar suas peças e seus dados.

Eu tenho um único repositório com todas as minhas funções, fatos etc. que são implantados em uma ampla variedade de sistemas de clientes. Garanto que todas as funções sejam recuperáveis ​​e livres de dados. Em host_vars/fqdn.ymlou group_vars/customer_name.ymldefino os dados que são exclusivos para esse cliente ou sistema remoto.

A maioria das minhas funções é expandida ao longo do tempo, conforme necessário, em vez de fazer tudo o from roles/foo/main.ymlque tenho, roles/foo/debian-foo.ymle roles/foo/openbsd-foo.ymlisso só é incluído quando o SO ou outra condição corresponde.

Simplificado, roles/adduser/main.ymlpode incluir o seguinte:

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

e group_vars/ACME.ymlpode incluir o seguinte:

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

No seu caso, pode ser bom ter ambientes separados em cada repositório git, desde que a pasta de funções seja um submódulo compartilhado que seja idêntico em todos os seus clientes.