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

Question

Eu tenho usado o Ansible, com grande sucesso, há ~ 3 anos para gerenciar um bando de sistemas linux cada vez maior. Antes de mergulhar na minha pergunta, preciso definir algum contexto.

Como parte do meu trabalho diário, eu faço projeto, implantação e manutenção de sistemas para várias empresas que operam sob a responsabilidade de uma única empresa de empreendimento / incubadora. Há muita polinização cruzada entre as empresas do 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 que o ambiente ansiável de cada empresa vive em um repositório git diferente. Isso significa que há um lote de 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 os 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 tive um < 5 usuários para gerenciar, mas à medida que a base de usuários cresce, torna-se cada vez mais oneroso manter as coisas atualizadas com a rotação de chaves, novas senhas etc.

Com a história e o contexto definidos, com a minha pergunta:

Supondo que usar um sistema de autenticação centralizado (LDAP, etc.) não é uma opção, como eu poderia lidar com a criação de um banco de dados de usuários centralizado que vários playbooks ansiosos poderiam consumir? Eu adoraria poder manter uma lista central de usuários, uids, hashes de senha e chaves públicas e, em seguida, ser capaz de implantar os usuários (com associações de grupo por host personalizadas) aos hosts de cada empresa.

Estou prevendo algum tipo de estrutura de jogo como:

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

... onde o uid, o hash e a chave pública de cada usuário seriam extraídos da lista central e implantados como de costume.

Então, quais opções eu tenho? Eu tenho pensado nisso por um bom tempo, e não consegui chegar a nada melhor do que o que eu já estou fazendo. Eu poderia fazer algo com um arquivo de fatos personalizado para manter meu banco de dados de usuários?

    

Answer 1

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

Eu tenho um único repo 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 resuíveis e livres de dados. Em host_vars/fqdn.yml ou group_vars/customer_name.yml defino 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 e, em vez de fazer tudo from roles/foo/main.yml , tenho roles/foo/debian-foo.yml e roles/foo/openbsd-foo.yml que são incluídas apenas quando o sistema operacional ou outra condição corresponder.

Simplificado, roles/adduser/main.yml pode incluir isso:

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

e group_vars/ACME.yml podem incluir isso:

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

No seu caso, pode ser OK ter ambientes ansible separados em cada reit git, desde que a pasta de papéis seja um submódulo compartilhado que seja idêntico em todos os seus clientes.