Automatiser la gestion des comptes d’administrateurs locaux avec Ansible – Partie 1

Je vais commencer par planter un peu le décor.

Tout fraîchement arrivé dans mon nouveau poste, je constate que je vais rapidement avoir à intervenir sur un très grand nombre de serveurs. Plus de 500 dans un premier temps, les 3/4 étant des variantes de distributions linux. Problème : je trouve trop compliqué de parvenir à avoir un accès administrateur sur chaque serveur sur lequel je vais devoir intervenir.

Dans la majorité des cas, il faut utiliser le compte root mais le mot de passe est souvent différent pour chaque serveur et consigné dans un logiciel de gestion de mots de passe. Bonjour la gymnastique pour arriver à se connecter ! Aussi, les admins de l’équipe en place se sont souvent créé un compte personnel sur ces serveurs de manière à pouvoir s’y connecter avec un identifiant / mot de passe personnel. C’est mieux d’utiliser un compte personnel, pour des raisons de tracabilité, mais c’est largement insuffisant d’en rester là.

En effet, avec cette gestion, pour que je puisse avoir un accès équivalent à celui des autres admins, il faudrait que je me connecte sur près 500 serveurs, pour à chaque fois me créer un compte personnel, changer mon mot de passe et me mettre dans un groupe de sudoers. Et en admettant que j’en fasse le tour, il reste que si un autre admin rejoint l’équipe, ou quitte l’équipe, il faut se refaire toutes ces manips. Inacceptable !

Et évidemment, cela a d’autres effets… Si un mot de passe d’administrateur est compromis, celui de root compris, c’est mort ! Parce que dans ce contexte, qui va prendre la peine de changer son mot de passe personnel régulièrement ?

Donc, quitte à m’atteler à la tâche, et à me farcir quelques centaines de serveurs, je décide d’en profiter pour améliorer la gestion des comptes d’admin et d’utiliser Ansible pour ça.

Pourquoi Ansible ?

Pour plusieurs raisons.

J’avais déjà une première solide expérience de Salt et une petite expérience d’Ansible que j’ai découvert un peu après Salt, et j’ai immédiatement préféré le second, en raison du fait que c’est plus facile à mettre au point, alors qu’avec Salt j’ai souvent galéré à comprendre la cause de certains messages d’erreur.

Avec Ansible, la gestion du parc est également plus simple. Dans Salt, il faut préalablement enrôler les machines (les minions) ce qui établit un lien entre le master Salt et le minion. Mais les opérations de clonage de VM me posaient ensuite problème car le master Salt se retrouvait ensuite avec deux minions ayant le même id, ce qui impliquait de ré-intervenir sur le master et les minions pour les dissocier.

Ansible me semble aussi beaucoup plus stable. Avec Salt j’avais souvent besoin de redémarrer un des démons impliqués, soit parce qu’il était planté, soit parce qu’il fallait prendre en compte des modifications de fichiers de conf. Avec Ansible, pas de démon, pas de problème.

Enfin, le fait qu’Ansible fonctionne sans installation préalable d’un agent sur les machines distantes est un sérieux avantage pour commencer à prendre la main sur un grand nombre de serveurs préexistants puisqu’il n’y a rien à y faire d’autre que d’y déposer une clé ssh. C’est discret, rapide, et ça consomme 0 mémoire quand on ne s’en sert pas. Et ça aussi c’est bien, parce que 500 x rien à installer et 500 x 0 mémoire consommée, ça fait toujours 0 🙂

Stratégie

Déjà, je viens d’arriver, alors je vais pas commencer par tout péter. Enfin, pas tout de suite 🙂

L’idée, c’est que chaque admin ait un compte personnel local sur chaque serveur, comme s’il avait été créé à la main. C’est simple, ça ne demande aucun recours à un outil tiers comme un ldap, et donc ça n’aura besoin d’aucune dépendance ou configuration particulière pour fonctionner. Mais de le faire avec Ansible permettra d’avoir la garantie d’avoir les mêmes comptes et mots de passe partout, et de pouvoir les créer, les modifier et les supprimer en un rien de temps.

Je me décide donc pour un plan en 3 phases 😉

  • générer une clé ssh dédiée à cet usage et la déposer partout
  • faire un état des lieux de la situation, afin d’identifier les comptes d’admin qui n’ont plus lieu d’être et les comptes douteux
  • et pour finir, enfin tout péter, c’est à dire supprimer les comptes indésirables, créer les comptes d’admin personnels et changer les mots de passe de tout ce petit monde, root compris

Et quand j’en serai arrivé là, promis, j’irai fêter ça dignement.

Malheureusement, si Ansible peut m’aider pour les deux dernières phases, pour la première, je dois me taper une grosse quantité de connexions ssh à la main.

Dans mes prochains articles je parlerai de mes 3 phases, avec pour commencer la préparation des hôtes pour les contrôler avec Ansible.

Laisser un commentaire