Comment puis-je mettre en œuvre ansible avec des mots de passe par hôte, en toute sécurité ?

Vous avez certainement fait vos recherches...

De toute mon expérience avec ansible, ce que vous cherchez à accomplir n'est pas supporté. Comme vous l'avez mentionné, ansible déclare qu'il ne nécessite pas de sudo sans mot de passe, et vous avez raison, il ne le fait pas. Mais je n'ai encore vu aucune méthode permettant d'utiliser plusieurs mots de passe sudo dans ansible, sans bien sûr exécuter plusieurs configurations.

Donc, je ne peux pas offrir la solution exacte que vous recherchez, mais vous avez demandé...

"Alors... comment les gens utilisent-ils Ansible dans des situations comme celles-ci ? Réglage de NOPASSWD dans /etc/sudoers, la réutilisation du mot de passe sur plusieurs hôtes ou l'activation de la connexion SSH de l'utilisateur root. la connexion SSH de la racine, tout cela semble plutôt réduire drastiquement la sécurité."

Je peux vous donner un avis sur la question. Dans mon cas, il s'agit de 1 000 nœuds répartis dans plusieurs centres de données qui soutiennent une entreprise mondiale de SaaS dans laquelle je dois concevoir/mettre en œuvre des contrôles de sécurité extrêmement stricts en raison de la nature de notre activité. La sécurité est toujours un acte d'équilibre, plus de convivialité moins de sécurité, ce processus n'est pas différent si vous exécutez 10 serveurs ou 1.000 ou 100.000.

Vous avez tout à fait raison de ne pas utiliser les connexions root, que ce soit par mot de passe ou par clé ssh. En fait, la connexion root doit être entièrement désactivée si un câble réseau est branché sur les serveurs.

Parlons de la réutilisation des mots de passe, dans une grande entreprise, est-il raisonnable de demander aux administrateurs système d'avoir des mots de passe différents sur chaque nœud ? pour quelques nœuds, peut-être, mais mes administrateurs/ingénieurs se mutineraient s'ils devaient avoir des mots de passe différents sur 1000 nœuds. L'implémentation de ce système serait également presque impossible, chaque utilisateur devrait stocker ses propres mots de passe quelque part, en espérant qu'il s'agisse d'un clavier, et non d'une feuille de calcul. Et chaque fois que vous mettez un mot de passe dans un endroit où il peut être extrait en texte clair, vous avez grandement diminué votre sécurité. Je préférerais qu'ils connaissent, par cœur, un ou deux mots de passe vraiment forts plutôt que de devoir consulter un fichier keypass chaque fois qu'ils ont besoin de se connecter ou d'invoquer sudo sur une machine.

La réutilisation et la normalisation des mots de passe sont donc des pratiques tout à fait acceptables et standard, même dans un environnement sécurisé. Sinon, ldap, keystone et les autres services d'annuaire n'auraient pas besoin d'exister.

Lorsque nous passons à des utilisateurs automatisés, les clés ssh fonctionnent très bien pour vous permettre d'entrer, mais vous devez toujours passer par sudo. Vous avez le choix entre un mot de passe standardisé pour l'utilisateur automatisé (ce qui est acceptable dans de nombreux cas) ou activer NOPASSWD comme vous l'avez indiqué. La plupart des utilisateurs automatisés n'exécutent que quelques commandes, il est donc tout à fait possible et certainement souhaitable d'activer NOPASSWD, mais uniquement pour les commandes pré-approuvées. Je vous suggère d'utiliser votre gestion de configuration (ansible dans ce cas) pour gérer votre fichier sudoers afin de pouvoir facilement mettre à jour la liste des commandes sans mot de passe.

Maintenant, il y a certaines mesures que vous pouvez prendre une fois que vous commencez à changer d'échelle pour isoler davantage le risque. Bien que nous ayons environ 1000 nœuds, tous ne sont pas des serveurs de "production", certains sont des environnements de test, etc. Tous les administrateurs ne peuvent pas accéder aux serveurs de production, mais ceux qui le peuvent utilisent le même utilisateur/passe/clé SSO qu'ailleurs. Mais les utilisateurs automatisés sont un peu plus sûrs. Par exemple, un outil automatisé auquel les administrateurs hors production peuvent accéder a un utilisateur et des informations d'identification qui ne peuvent pas être utilisés en production. Si vous voulez lancer ansible sur tous les nœuds, vous devez le faire en deux lots, une fois pour la non-production et une fois pour la production.

Nous utilisons également Puppet, car il s'agit d'un outil de gestion de la configuration, et la plupart des changements apportés à tous les environnements passent par lui.

Évidemment, si la demande de fonctionnalité que vous avez citée est rouverte/complétée, ce que vous cherchez à faire serait entièrement pris en charge. Mais même dans ce cas, la sécurité est un processus d'évaluation des risques et des compromis. Si vous n'avez que quelques nœuds dont vous pouvez vous rappeler les mots de passe sans avoir recours à un post-it, des mots de passe séparés seraient légèrement plus sûrs. Mais pour la plupart d'entre nous, ce n'est pas une option réalisable.

À partir de la version 1.5 d'Ansible, il est possible d'utiliser un fichier de type coffre-fort crypté pour host_vars et autres variables. Cela vous permet au moins de stocker une variable par hôte (ou par groupe). ansible_sudo_pass variable en toute sécurité. Malheureusement, --ask-vault-pass ne demandera qu'un seul mot de passe de chambre forte par invocation ansible, donc vous êtes toujours contraint à un seul mot de passe de chambre forte pour tous les hôtes que vous utiliserez ensemble.

Néanmoins, pour certaines utilisations, cela peut être une amélioration par rapport au fait d'avoir un seul mot de passe sudo sur plusieurs hôtes, car un attaquant n'ayant pas accès à vos host_vars chiffrées aurait toujours besoin d'un mot de passe sudo distinct pour chaque machine (ou groupe de machines) qu'il attaque.

Avec Ansible 1.5, il est possible de définir l'option ansible_sudo_pass variable en utilisant lookup('password', …) :

ansible_sudo_pass: "{{ lookup('password', 'passwords/' + inventory_hostname) }}"

Je trouve cela plus pratique que d'utiliser des fichiers dans host_vars/ pour plusieurs raisons :

• En fait, j'utilise with_password: "passwords/{{ inventory_hostname}} encrypt=sha256_crypt" pour provisionner les mots de passe pour les déployer utilisateur distant (qui est ensuite nécessaire pour sudo ), donc ils sont déjà présents dans les fichiers (bien qu'en faisant ces recherches en clair, on perd la valeur du sel stockée dans le fichier lorsque la valeur hachée est générée).

• Cela permet de conserver uniquement les mots de passe dans le fichier (pas de ansible_sudo_pass: texte en clair connu) pour une augmentation d'epsilon de la sécurité cryptographique. Plus significativement, cela signifie que vous ne chiffrez pas toutes les autres variables spécifiques à l'hôte, donc elles peuvent être lues sans le mot de passe de la chambre forte.

• En plaçant les mots de passe dans un répertoire séparé, il est plus facile de garder les fichiers hors du contrôle de source, ou d'utiliser un outil comme git-crypt pour les stocker sous forme cryptée (vous pouvez l'utiliser avec les versions antérieures d'Ansible qui ne disposent pas de la fonction de coffre-fort). J'utilise git-crypt et comme je ne consulte le dépôt que sous forme déchiffrée sur des systèmes de fichiers chiffrés, je ne m'occupe pas de la chambre forte et n'ai donc pas besoin de taper un mot de passe de chambre forte. (L'utilisation des deux serait bien sûr plus sûre).

Vous pouvez également utiliser le recherche fonction avec ansible_ssh_pass ; cela peut même être possible avec des versions antérieures d'Ansible qui ne disposent pas de ansible_sudo_pass .

Utilisation de passer est une méthode simple pour fournir à ansible des mots de passe sudo. pass stocke un mot de passe par fichier ce qui rend facile le partage des mots de passe via git ou d'autres méthodes. C'est également sécurisé (en utilisant GnuPG) et si vous utilisez gpg-agent, cela vous permet d'utiliser ansible sans avoir à entrer un mot de passe à chaque utilisation.

Pour fournir le mot de passe stocké comme servers/foo pour le serveur foo à ansible, utilisez-le dans un fichier d'inventaire comme ceci :

[servers]
foo ansible_sudo=True \
    ansible_sudo_pass="{{ lookup('pipe', 'pass servers/foo') }}"

Étant donné que vous avez déverrouillé la clé pour gpg-agent plus tôt, ceci lancera ansible sans avoir besoin d'entrer un mot de passe.

Mise à jour : Ansible a cette fonctionnalité intégrée aujourd'hui, par le biais de la fonction plugin passwordstore . L'équivalent de ce qui précède serait :

[servers]
foo ansible_sudo=True \
    ansible_sudo_pass="{{ lookup('passwordstore', 'servers/foo') }}"

Il est même possible de créer un mot de passe s'il n'existe pas encore, ce qui peut être extrêmement utile.

Il s'agit néanmoins d'un fil de discussion assez ancien :

• Nous utilisons deux systèmes d'authentification différents en interne, la gestion des machines se fait depuis les postes de travail locaux de mon équipe.
• J'ai écrit un vars_plugin pour Ansible (une implémentation assez complète se trouve à l'adresse suivante https://gist.github.com/mfriedenhagen/e488235d732b7becda81 ) qui différencie plusieurs systèmes d'authentification :
• Le nom du système d'authentification est spécifique au groupe.
• L'utilisateur utilisé pour le login/sudo est spécifique au groupe et à l'administrateur.
• Je tire donc l'utilisateur de l'environnement de l'administrateur et le mot de passe correspondant via la bibliothèque Python-keyring à partir d'un coffre-fort de mots de passe (nous utilisons le trousseau de Mac OS X, mais d'après la documentation, kwallet Gnome et _win_crypto sont également supportés).
• J'ai défini des permissions sur les mots de passe dans le trousseau de Mac OS X pour m'avertir du fait que le programme en ligne de commande security demande l'accès à un mot de passe pour chaque système d'authentification utilisé par les hôtes, donc je lance "ansible -s all -m ping" et j'obtiens deux invites (une pour chaque système d'authentification) où j'appuie sur la barre d'espace et ansible récupère les mots de passe.