Question Comment puis-je implémenter ansible avec des mots de passe par hôte, en toute sécurité?


Je voudrais utiliser ansible pour gérer un groupe de serveurs existants. J'ai créé un ansible_hosts fichier et testé avec succès (avec le -K option) avec des commandes qui ne ciblent qu'un seul hôte

ansible -i ansible_hosts host1 --sudo -K # + commands ...

Mon problème actuel est que les mots de passe des utilisateurs sur chaque hôte sont différents, mais je ne trouve pas de moyen de gérer cela dans Ansible.

En utilisant -K, Je ne suis invité à entrer qu'un seul mot de passe sudo dès le départ, qui semble alors être essayé pour tous les hôtes suivants sans demander:

host1 | ...
host2 | FAILED => Incorrect sudo password
host3 | FAILED => Incorrect sudo password
host4 | FAILED => Incorrect sudo password
host5 | FAILED => Incorrect sudo password

Recherche jusqu'ici:

  • une Question StackOverflow avec une réponse incorrecte ("utiliser -K") et une réponse de l'auteur disant" J'ai découvert qu'il me fallait sudo sans mot de passe "

  • les documents Ansible, qui dit "L'utilisation de sudo sans mot de passe facilite l'automatisation, mais ce n'est pas nécessaire. "(c'est moi qui souligne)

  • cette question de sécurité StackExchange qui prend comme lu que NOPASSWD est requis

  • article "Approvisionnement évolutif et compréhensible ..." qui dit:

    "Pour exécuter sudo, il peut être nécessaire de saisir un mot de passe, ce qui est un moyen sûr de bloquer Ansible. Une solution simple consiste à exécuter visudo sur l'hôte cible et à s'assurer que l'utilisateur qu'Ansible utilisera pour se connecter ne doit pas entrer de mot de passe"

  • article "Playbooks Ansible de base"qui dit

    "Ansible peut se connecter au serveur cible en tant que root et éviter la nécessité de sudo, ou laisser l'utilisateur de ansible le faire sans mot de passe, mais la pensée de le faire oblige ma rate à menacer de me projeter dans le gosier et de bloquer ma trachée. ne pas "

    Mes pensées exactement, mais alors comment s'étendre au-delà d'un seul serveur?

  • numéro ansible 1227, "Ansible devrait demander un mot de passe sudo pour tous les utilisateurs d'un livre de jeu", qui a été fermé il y a un an par mpdehaan avec le commentaire "Je n'ai pas vu beaucoup de demande pour cela, je pense que la plupart des gens utilisent un seul compte utilisateur ou utilisent clés la plupart du temps. "

Alors… comment les gens utilisent-ils Ansible dans de telles situations? Réglage NOPASSWD dans /etc/sudoers, la réutilisation du mot de passe sur plusieurs hôtes ou l’activation de la connexion SSH racine semblent constituer des réductions drastiques de la sécurité.


97
2017-12-09 11:49


origine


Y a-t-il une raison pour laquelle vous n'utilisez pas de clés SSH? - Trondh
J'utilise déjà les clés SSH; ils n'affectent pas sudo (qui devrait quand même nécessiter un mot de passe). - supervacuo
Ce n'est peut-être pas exactement ce que vous recherchez, mais sur les boîtes Ubuntu, j'utilise toujours des clés, c'est-à-dire que je mets ma clé publique dans / root / registered_keys pour obtenir directement en tant que root. Un inconvénient évident est d'autoriser les connexions root sur ssh ... J'interdit également les connexions de mot de passe sur ssh et lance fail2ban pour plus de sécurité. - senorsmile
@senorsmile merci pour la réponse! Est-ce que cela vous dérangerait d'en faire une réponse pour que je puisse vous inviter à ne pas lire la question? - supervacuo
c'est à dire. la ansible_ssh_password Ce paramètre s'applique uniquement au mot de passe SSH (l'indice est dans le nom ...). & J'utilise déjà la connexion SSH basée sur des clés. - supervacuo


Réponses:


Vous avez certainement fait vos recherches ...

D'après toute mon expérience avec ansible, ce que vous cherchez à accomplir n'est pas pris en charge. Comme vous l'avez mentionné, ansible déclare qu'il n'est pas nécessaire d'utiliser sudo sans mot de passe, et vous avez raison, ce n'est pas le cas. Mais je n'ai pas encore vu de méthode pour utiliser plusieurs mots de passe sudo dans ansible, sans exécuter plusieurs configs.

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

"Alors ... comment les gens utilisent-ils Ansible dans de telles situations?   NOPASSWD dans / etc / sudoers, réutilisation du mot de passe sur plusieurs hôtes ou activation   Les connexions SSH root semblent toutes réduire de manière assez drastique la sécurité. "

Je peux vous donner un avis à ce sujet. Mon cas d'utilisation est constitué de 1 000 nœuds dans plusieurs centres de données prenant en charge une entreprise SaaS globale dans laquelle je dois concevoir / mettre en œuvre des contrôles de sécurité extrêmement stricts en raison de la nature de nos activités. La sécurité est toujours un é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 personnes.

Vous avez absolument 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 connecté aux 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. En outre, il serait presque impossible de mettre en œuvre cette solution, chaque utilisateur devant stocker ses propres mots de passe quelque part, espérons-le, un clavier numérique, pas un tableur. Et chaque fois que vous placez un mot de passe dans un emplacement où il peut être extrait en texte brut, votre sécurité est considérablement réduite. Je préférerais qu'ils sachent, par cœur, un ou deux mots de passe très forts, plutôt que de devoir consulter un fichier de clés chaque fois qu'ils ont besoin de se connecter ou d'appeler sudo sur une machine.

Ainsi, la réutilisation des mots de passe et la normalisation sont totalement acceptables et standard même dans un environnement sécurisé. Sinon, les services de répertoire LDAP, Keystone et autres n'auraient pas besoin d'exister.

Lorsque nous passons aux utilisateurs automatisés, les clés ssh fonctionnent très bien pour vous permettre d'entrer, mais vous devez tout de même passer à travers sudo. Vous avez le choix entre un mot de passe normalisé pour l'utilisateur automatisé (ce qui est acceptable dans de nombreux cas) ou pour 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 souhaitable d'activer NOPASSWD, mais uniquement pour les commandes pré-approuvées. Je suggérerais d'utiliser votre gestion de la configuration (ansible dans ce cas) pour gérer votre fichier sudoers afin que vous puissiez facilement mettre à jour la liste des commandes sans mot de passe.

À présent, vous pouvez prendre certaines mesures une fois que vous avez commencé à mettre à l'échelle pour isoler davantage les risques. Bien que nous ayons environ 1 000 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-ci peuvent utiliser leur même clé d'utilisateur / mot de passe SSO comme ailleurs. . Mais les utilisateurs automatisés sont un peu plus sécurisés, par exemple un outil automatisé auquel les administrateurs non producteurs peuvent accéder a un utilisateur et des informations d'identification qui ne peuvent pas être utilisées en production. Si vous souhaitez lancer ansible sur tous les nœuds, vous devez le faire en deux lots, une pour la non-production et une autre pour la production.

Nous utilisons également marionnette, car il s’agit d’un outil de gestion de la configuration contraignant, de sorte que la plupart des modifications apportées à tous les environnements sont forcées de s’en sortir.

É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. Même dans ce cas, la sécurité est un processus d’évaluation des risques et de compromis. Si vous ne pouvez mémoriser les mots de passe que pour quelques nœuds sans avoir recours à un post-it, des mots de passe distincts seraient légèrement plus sécurisés. Mais pour la plupart d'entre nous, ce n'est pas une option réalisable.


52
2017-12-30 16:53



Merci, @Zeb - J'avais imaginé que les utilisateurs disposant de dizaines de milliers de serveurs utiliseraient NOPASSWD pour des raisons de sécurité quand même (probablement soutenu par des règles de pare-feu plus strictes) etc.), mais il est bon de lire votre cas d'utilisation et vos réflexions sur le modèle de menace. - supervacuo
Un commentaire, cependant, sur votre suggestion de limiter à "pré-approuvé" sudo commandes (ce qui m’est venu à l’esprit quand j’ai découvert que NOPASSWD est à peu près nécessaire). Malheureusement, cela semble complètement non supporté aussi bien - ansible ne fait aucune promesse d'appeler par exemple.  chown ou mkdir binaires directement et doit pouvoir sudo /bin/sh pour que la plupart des modules fonctionnent. - supervacuo
Il me semble que l'un de mes ingénieurs s'est plaint de cela il y a quelque temps, c'est agaçant. - Zeb


À partir de Ansible 1.5, il est possible d’utiliser un emplacement de stockage chiffré pour host_vars et autres variables. Cela vous permet au moins de stocker un hôte par hôte (ou par groupe). ansible_sudo_passvariable en toute sécurité. Malheureusement, --ask-vault-pass n’invitera qu’un seul mot de passe de coffre-fort pour chaque appel, de sorte que vous serez toujours contraint à un seul mot de passe de coffre-fort pour tous les hôtes que vous utiliserez ensemble.

Néanmoins, pour certaines utilisations, cela peut représenter une amélioration par rapport à la présence d'un mot de passe sudo unique sur plusieurs hôtes, car un attaquant sans accès à vos hôtes chiffrés aurait toujours besoin d'un mot de passe sudo distinct pour chaque machine (ou groupe de machines) qu'il attaque.


36
2018-05-10 20:32



le ansible_sudo_pass L’option semble nouvelle aussi - et semble faire ce que je demandais. Un mot de passe unique pour le coffre-fort est également idéal. Merci! - supervacuo
Y a-t-il un moyen d'éviter de chiffrer tout  host_vars en utilisant cette méthode? (une limitation potentielle notée par Alex Dupuy) - supervacuo
@supervacuo - Pour éviter de chiffrer tous les vars hôtes, utilisez simplement un répertoire var hôte contenant main.yml (non crypté) et secret.yml (crypté) - voir la dernière partie de cette section doc où il est question du groupe "raleigh" - la même technique fonctionne pour les serveurs hôtes et les serveurs de groupe. J'utilise beaucoup cela, la seule variante est que si un secret n'est requis que par certains playbooks, il peut être utile de le stocker entièrement dans une arborescence différente et de l'inclure via un chemin qui inclut le nom d'hôte ou de var. - RichVel
Si j'ai chiffré la valeur 'ansible_ssh_pass' dans le coffre-fort, j'ai donc également besoin de dupliquer la valeur 'ansible_sudo_pass'? Existe-t-il un moyen pour la seconde valeur sudo_pass de faire référence à la première valeur 'ssh_pass'? - emeraldjava


Avec Ansible 1.5, il est possible de définir le ansible_sudo_pass variable 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:

  • J'utilise réellement with_password: "passwords/{{ inventory_hostname}} encrypt=sha256_crypt" pour fournir les mots de passe pour le déployer utilisateur distant (qui est alors nécessaire pour sudo), ils sont donc déjà présents dans les fichiers (bien que ces recherches en texte brut perdent la valeur de sel stockées dans le fichier lorsque la valeur hachée est générée).

  • Ceci ne conserve que les mots de passe dans le fichier (pas ansible_sudo_pass: texte en clair connu) pour certains epsilon augmentation de la sécurité cryptographique. Plus important encore, cela signifie que vous ne chiffrez pas toutes les autres variables spécifiques à l'hôte, afin qu'ils puissent être lus sans le mot de passe du coffre-fort.

  • En plaçant les mots de passe dans un répertoire distinct, il est plus facile de garder les fichiers en dehors du contrôle de la source ou d'utiliser un outil tel que git-crypt pour les stocker sous forme chiffrée (vous pouvez utiliser cela avec Ansible antérieur qui ne possédait pas la fonctionnalité de coffre-fort). J'utilise git-crypt et, comme je ne vérifie le référentiel que sous forme déchiffrée sur des systèmes de fichiers chiffrés, je ne me soucie pas du coffre-fort et je n'ai donc pas besoin de taper un mot de passe du coffre-fort. (Utiliser les deux serait bien sûr plus sûr.)

Vous pouvez également utiliser le Chercher fonctionner avec ansible_ssh_pass; cela peut même être possible avec des versions antérieures d'Ansible qui n'ont pas ansible_sudo_pass.


22
2018-05-26 19:33



je enfin eu le temps d'essayer (merci!), mais je ne vois pas comment cela fonctionnerait sans git-crypt; d'aussi loin que je puisse voir. Il semble que Ansible n'a pas encore de support pour l'utilisation lookup sur un coffre-fort chiffré. le password documentation du module disons qu'il existe un support non encore documenté pour le stockage crypté, mais que je n'ai pas encore trouvé de détails. Des indices? - supervacuo


En utilisant passer est une méthode simple pour fournir des mots de passe sudo à ansible. pass stocke un mot de passe par fichier, ce qui facilite le partage des mots de passe via git ou d'autres méthodes. Il est également sécurisé (avec GnuPG) et si vous utilisez gpg-agent, il vous permet d’utiliser ansible sans saisir de mot de passe pour chaque utilisation.

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

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

Etant donné que vous avez déverrouillé la clé pour gpg-agent plus tôt, cela fonctionnera automatiquement sans qu'il soit nécessaire d'entrer un mot de passe.


17
2018-01-19 19:51



Une telle excellente solution - merci! - Leng


C'est un fil assez ancien, néanmoins:

  • Nous utilisons deux systèmes d’authentification différents en interne. La gestion des machines est effectuée à partir des stations de travail locales de mon équipe.
  • J'ai écrit un vars_plugin pour Ansible (une implémentation assez complète peut être trouvée à https://gist.github.com/mfriedenhagen/e488235d732b7becda81) qui différencie plusieurs systèmes d'authentification:
  • Le nom du système d'authentification est spécifique à un groupe.
  • L'utilisateur login / sudo utilisé est spécifique au groupe et à l'administrateur.
  • Je tire donc l'utilisateur de l'environnement de l'administrateur et du mot de passe correspondant via la bibliothèque python-keyring d'un mot de passe sécurisé (nous utilisons le trousseau de Mac OS X, mais la documentation kwallet Gnome et _win_crypto sont également pris en charge).
  • Je mets des autorisations sur les mots de passe dans le trousseau de Mac OS X pour m'avertir du fait que la sécurité du programme en ligne de commande demande l'accès à un mot de passe pour chaque système d'authentification utilisé par les hôtes, alors je lance "ansible -s all -m ping" et je reçois 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.

3
2018-03-03 17:33



Cela a l'air très chouette, merci - j'aime bien l'idée de ne pas avoir à stocker les mots de passe à deux endroits. Pour le moment, je suis bloqué sous KeepassX (car le trousseau de clés GNOME ne semble pas très portable) mais je peux peut-être python-keepass travail? - supervacuo
Autant que je sache, python-keyring est une abstraction pour cela, vos collègues peuvent donc utiliser d'autres systèmes d'exploitation. Ou stockez-vous votre base de données keepassx sur une clé USB et devez-vous l’administrer à partir de postes de travail sous différents systèmes d’exploitation? - Mirko Friedenhagen
compris; Je voulais dire que je devais déjà utiliser KeepassX pour avoir accès aux mots de passe sur des systèmes non-GNOME, donc les stocker dans gnome-keyring signifierait conserver des enregistrements en double. Encore mieux que d'utiliser NOPASSWD, bien que… - supervacuo


Une méthode possible consiste à utiliser des variables environnementales.

par exemple.

pass1=foo pass2=bar ansible-playbook -i production servers.xml

Ensuite, dans les jeux, vous pouvez rechercher le mot de passe sudo en utilisant:

lookup('env', 'pass1') 
lookup('env', 'pass2') 

0
2017-07-21 08:57