Quelle est la situation actuelle de la gestion des utilisateurs avec Ansible?


10

J'utilise Ansible, avec beaucoup de succès, depuis environ 3 ans maintenant pour gérer un troupeau toujours croissant de systèmes Linux. Avant de plonger dans ma question, je dois mettre un peu de contexte.

Dans le cadre de mon travail de jour, je fais de la conception, du déploiement et de la maintenance de systèmes pour diverses entreprises qui opèrent toutes sous l'égide d'une seule entreprise / incubateur. Il y a beaucoup de pollinisation croisée parmi nos sociétés de portefeuille, et en tant que tel, nous ne pouvons pas dire que seuls les utilisateurs A, B et C auront besoin d'accéder aux systèmes de la société X. Ils peuvent également avoir besoin d'accéder aux systèmes de l'entreprise Y. Cela est compliqué par le fait que l'environnement ansible de chaque entreprise vit dans un référentiel git différent. Cela signifie qu'il y a beaucoup de duplication de code pour déployer des utilisateurs sur les systèmes de différentes sociétés. Je finis par copier / coller des blocs de code comme celui-ci pour déployer des utilisateurs sur les systèmes d'une certaine entreprise:

- 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

Cela a bien fonctionné lorsque j'avais moins de 5 utilisateurs à gérer, mais à mesure que la base d'utilisateurs augmente, il devient de plus en plus onéreux de tenir à jour la rotation des clés, les nouveaux mots de passe, etc.

Avec la trame de fond et le contexte définis, avec ma question:

En supposant que l'utilisation d'un système d'authentification centralisée (LDAP, etc.) n'est pas une option, comment pourrais-je aborder la création d'une base de données utilisateur centralisée que divers playbooks ansible pourraient consommer? J'aimerais pouvoir conserver une liste centrale d'utilisateurs, d'uids, de hachages de mot de passe et de clés publiques, puis être en mesure de déployer les utilisateurs (avec des adhésions personnalisées par groupe d'hôtes) aux hôtes de chaque entreprise.

J'imagine une sorte de structure de jeu comme:

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

... où l'uid, le hachage et la clé publique de chaque utilisateur seraient extraits de la liste centrale et déployés comme d'habitude.

Alors, quelles options ai-je? Je réfléchis à cela depuis un bon moment et je n'ai pas pu trouver mieux que ce que je fais déjà. Puis-je faire quelque chose avec un fichier de faits personnalisé pour conserver ma base de données d'utilisateurs?

Réponses:


8

Vous devez séparer vos jeux et vos données.

J'ai un référentiel unique avec tous mes rôles, faits, etc. qui se déploient sur une large gamme de systèmes clients. Je m'assure que tous les rôles sont réutilisables et sans données. Dans host_vars/fqdn.ymlou group_vars/customer_name.ymlje définis les données propres à ce client ou à ce système distant.

La plupart de mes rôles sont élargis au fil du temps au besoin et au lieu de faire tout ce que from roles/foo/main.ymlj'ai roles/foo/debian-foo.ymlet roles/foo/openbsd-foo.ymlqui ne sont inclus que lorsque le système d'exploitation ou une autre condition correspond.

Simplifié, roles/adduser/main.ymlpourrait inclure ceci:

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

et group_vars/ACME.ymlpourrait inclure ceci:

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

Dans votre cas, il peut être correct d'avoir des environnements ansibles séparés dans chacun de leurs git repo tant que le dossier de rôles est un sous-module partagé qui est identique pour tous vos clients.


Cela me pointe dans la bonne direction. Merci Alex! Je devrai encore trouver comment gérer une base de données unique de noms d'utilisateurs / clés / uids / etc que je peux référencer à partir de divers rôles et / ou groupes, mais je pense avoir quelques idées sur la façon dont je peux y parvenir.
EEAA

1
@EEAA Souvenez-vous que roles / all peut être un répertoire avec des fichiers afin que vous puissiez facilement centraliser les rôles / all / staff.yml, roles / all / foo.yml, etc.
Alex Holst
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.