web-dev-qa-db-fra.com

Spécifiez le mot de passe Sudo pour Ansible

Comment puis-je spécifier un mot de passe Sudo pour Ansible de manière non interactive?

J'exécute Ansible playbook comme ceci:

ansible-playbook playbook.yml -i inventory.ini --user=username --ask-Sudo-pass

Mais je veux le lancer comme ça:

ansible-playbook playbook.yml -i inventory.ini --user=username --Sudo-pass = 12345

Y a-t-il un moyen? Je souhaite automatiser autant que possible le déploiement de mon projet.

ansible
167
Slava Fomin II

Vous pouvez passer variable sur la ligne de commande via --extra-vars "name=value". La variable de mot de passe Sudo est ansible_Sudo_pass. Donc, votre commande ressemblerait à ceci:

ansible-playbook playbook.yml -i inventory.ini --user=username \
                              --extra-vars "ansible_Sudo_pass=yourPassword"

Mise à jour 2017 : Ansible 2.2.1.0 utilise maintenant var ansible_become_pass. Soit semble fonctionner.

114
Alexandr Nikitin

La documentationfortement recommande de ne pas définir le mot de passe Sudo en texte brut, mais d'utiliser plutôt --ask-Sudo-pass sur la ligne de commande lors de l'exécution de ansible-playbook.

Mise à jour 2016:

Ansible 2.0 (pas 100% lorsque) a marqué --ask-Sudo-pass comme obsolète. Les docs recommandent maintenant d'utiliser --ask-become-pass à la place, tout en remplaçant l'utilisation de Sudo dans vos playbooks par become.

184
deefour

La meilleure façon de procéder est probablement d’utiliser la solution de Mircea Vutcovici en combinaison avec Ansible vault . 

Par exemple, vous pourriez avoir un livre de lecture qui ressemble à ceci: 

- hosts: all

  vars_files:
    - secret

  tasks:
    - name: Do something as Sudo
      service: name=nginx state=restarted
      Sudo: yes

Nous incluons ici un fichier appelé secret qui contiendra notre mot de passe Sudo. 

Nous allons utiliser ansible-vault pour créer une version chiffrée de ce fichier:

ansible-vault create secret

Cela vous demandera un mot de passe, puis ouvrez votre éditeur par défaut pour éditer le fichier. Vous pouvez mettre votre ansible_Sudo_pass ici. 

exemple: secret:

ansible_Sudo_pass: mysudopassword

Sauvegarder et quitter, vous avez maintenant un fichier secret chiffré que Ansible est capable de déchiffrer lorsque vous exécutez votre livre de lecture. Remarque: vous pouvez éditer le fichier avec ansible-vault edit secret (et entrez le mot de passe que vous avez utilisé lors de la création du fichier).

La dernière pièce du puzzle consiste à fournir à Ansible un --vault-password-file qu’il utilisera pour déchiffrer votre fichier secret.

Créez un fichier appelé vault.txt et insérez le mot de passe que vous avez utilisé lors de la création de votre fichier secret. Le mot de passe doit être une chaîne stockée sur une seule ligne du fichier.

De la Ansible Docs:

.. assurez-vous que les autorisations sur le fichier sont telles que personne d'autre ne peut accéder à votre clé et n'ajoutez pas votre clé au contrôle de source

Enfin: vous pouvez maintenant exécuter votre playbook avec quelque chose comme

ansible-playbook playbook.yml -u someuser -i hosts --Sudo --vault-password-file=vault.txt

Ce qui précède suppose la structure de répertoire suivante:

.
|_ playbook.yml
|_ secret
|_ hosts
|_ vault.txt

Vous pouvez en savoir plus sur Ansible Vault ici: https://docs.ansible.com/playbooks_vault.html

89
toast38coza

En regardant le code ( runner/__init__.py ), je pense que vous pouvez probablement le définir dans votre fichier d'inventaire:

[whatever]
some-Host ansible_Sudo_pass='foobar'

Il semble y avoir une disposition dans le fichier de configuration ansible.cfg également, mais elle n’a pas encore été mise en œuvre ( constants.py ).

41
leucos

Je ne pense pas que ansible vous laissera spécifier un mot de passe dans les drapeaux comme vous le souhaitez. Il peut y avoir quelque part dans les configs que cela peut être défini, mais cela rendrait l’utilisation de ansible moins sécurisé et ne serait pas recommandé.

Vous pouvez, par exemple, créer un utilisateur sur la machine cible et lui accorder des privilèges Sudo sans mot de passe pour toutes les commandes ou pour une liste restreinte de commandes.

Si vous exécutez Sudo visudo et entrez une ligne similaire à celle ci-dessous, l'utilisateur 'privilegedUser' ne devrait pas avoir à entrer de mot de passe pour exécuter quelque chose comme Sudo service xxxx start:

%privilegedUser ALL= NOPASSWD: /usr/bin/service
40
scottod

Le mot de passe Sudo est stocké sous forme de variable appelée ansible_Sudo_pass. Vous pouvez définir cette variable de plusieurs manières:

Par hôte, dans votre fichier d'hôtes d'inventaire (inventory/<inventoryname>/hosts) 

[server]
10.0.0.0 ansible_Sudo_pass=foobar

Par groupe, dans votre fichier de groupes d'inventaire (inventory/<inventoryname>/groups)

[server:vars]
ansible_Sudo_pass=foobar

Par groupe, dans groupe vars (group_vars/<groupname>/ansible.yml)

ansible_Sudo_pass: "foobar"

Par groupe, crypté (ansible-vault create group_vars/<groupname>/ansible.yml)

ansible_Sudo_pass: "foobar"
17
Bouke Versteegh

Vous pouvez définir le mot de passe pour un groupe ou pour tous les serveurs à la fois:

[all:vars]
ansible_Sudo_pass=default_Sudo_password_for_all_hosts

[group1:vars]
ansible_Sudo_pass=default_Sudo_password_for_group1
16
Mircea Vutcovici

J'étais en train de m'arracher les cheveux, maintenant j'ai trouvé une solution qui fait ce que je veux:

1 fichier crypté par hôte contenant le mot de passe Sudo

/ etc/ansible/hosts:

[all:vars]
ansible_ssh_connection=ssh ansible_ssh_user=myuser ansible_ssh_private_key_file=~/.ssh/id_rsa

[some_service_group]
node-0
node-1

ensuite, vous créez pour chaque hôte un fichier var crypté comme ceci:

ansible-vault create /etc/ansible/Host_vars/node-0

avec contenu

ansible_Sudo_pass: "my_Sudo_pass_for_Host_node-0"

comment vous organisez le mot de passe du coffre-fort (entrez via --ask-vault-pass) ou par cfg, c'est vous qui décidez

sur cette base, je soupçonne que vous pouvez simplement chiffrer tout le fichier hosts ...

11
greenone83

Une façon plus avisée de le faire est de stocker votre mot de passe Sudo dans un emplacement sécurisé tel que LastPass ou KeePass puis de le transmettre à ansible-playbook en utilisant le -e@ mais au lieu de coder en dur le contenu d'un fichier, vous pouvez utiliser la construction -e@<(...) pour exécuter une commande dans un sous-shell et rediriger sa sortie (STDOUT) vers un descripteur de fichier anonyme, en fournissant efficacement le mot de passe à -e@<(..).

Exemple

$ ansible-playbook -i /tmp/hosts pb.yml \
   -e@<(echo "ansible_Sudo_pass: $(lpass show folder1/item1 --password)")

Ce qui précède fait plusieurs choses, décomposons-le.

  • ansible-playbook -i /tmp/hosts pb.yml - exécuter un playbook évidemment avec ansible-playbook
  • $(lpass show folder1/item1 --password)" - exécute LastPass CLI lpass et récupère le mot de passe à utiliser
  • echo "ansible_Sudo_pass: ...password..." - prend la chaîne 'ansible_Sudo_pass:' et la combine avec le mot de passe fourni par lpass
  • -e@<(..) - rassemble les éléments ci-dessus et connecte le sous-shell de <(...) en tant que descripteur de fichier que ansible-playbook doit consommer.

Autres améliorations

Si vous préférez ne pas taper cela à chaque fois, vous pouvez simplement utiliser des choses comme ça. Commencez par créer un alias dans votre .bashrc comme suit:

$ cat ~/.bashrc
alias asp='echo "ansible_Sudo_pass: $(lpass show folder1/item1 --password)"'

Maintenant, vous pouvez lancer votre playbook comme ceci:

$ ansible-playbook -i /tmp/hosts pb.yml -e@<(asp)

Références

4
slm

Si vous souhaitez conserver les mots de passe dans des fichiers de texte brut, vous pouvez également utiliser un fichier JSON avec le paramètre --extra-vars (veillez à exclure le fichier du contrôle de code source):

ansible-playbook --extra-vars "@private_vars.json" playbook.yml

Ansible prend en charge cette option depuis la version 1.3 .

4
sidecarcat

Un coffre Ansible a été suggéré à quelques reprises ici, mais je préfère git-crypt pour chiffrer des fichiers sensibles dans mes playbooks. Si vous utilisez git pour garder vos playbooks ansible, c'est très simple. Le problème que j'ai trouvé avec ansible vault est que je finis inévitablement par trouver des copies chiffrées du fichier avec lequel je veux travailler et que je dois le déchiffrer avant de pouvoir travailler. git-crypt offre un meilleur flux de travail IMO.

En utilisant ceci, vous pouvez mettre vos mots de passe dans une variable de votre playbook, et marquer votre playbook en tant que fichier chiffré dans .gitattributes comme ceci:

 my_playbook.yml filter=git-crypt diff=git-crypt

Votre Playbook sera crypté de manière transparente sur Github. Ensuite, il vous suffit d’installer votre clé de chiffrement sur l’hôte que vous utilisez pour exécuter ansible ou de suivre les instructions de la documentation pour le configurer avec gpg.

Il existe de bonnes questions-réponses sur le transfert de clés gpg telles que votre ssh-agent transfère les clés SSH ici: https://superuser.com/questions/161973/how-can-i-forward-a-gpg-key-via-ssh-agent .

4
user2432419

vous pouvez écrire le mot de passe Sudo pour votre playbook dans le fichier hosts de la manière suivante:

[Host-group-name]
Host-name:port ansible_Sudo_pass='*your-Sudo-password*'
3
user3343297

Vous pouvez utiliser l'utilitaire sshpass comme ci-dessous,

$ sshpass -p "your pass" ansible pattern -m module -a args \
   -i inventory --ask-Sudo-pass
2
Sachin

Appelez votre Playbook avec --extra-vars "become_pass=Password"

devenir_pass = ('ansible_become_password', 'ansible_become_pass')

2
Crypto

Utiliser ansible 2.4.1.0 et ce qui suit doit fonctionner:

[all]
17.26.131.10
17.26.131.11
17.26.131.12
17.26.131.13
17.26.131.14

[all:vars]
ansible_connection=ssh
ansible_user=per
ansible_ssh_pass=per
ansible_Sudo_pass=per

Et lancez simplement le playbook avec cet inventaire en tant que:

ansible-playbook -i inventory copyTest.yml
0
Hearen

Mon hack pour automatiser cela consistait à utiliser une variable d'environnement et à y accéder via --extra-vars="ansible_become_pass='{{ lookup('env', 'ANSIBLE_BECOME_PASS') }}'".

Exportez une variable env, mais évitez l’historique bash/Shell (ajoutez un espace, ou d’autres méthodes). Par exemple.:

     export ANSIBLE_BECOME_PASS='<your password>'

Cherchez la variable env en passant la variable extra ansible_become_pass dans la ansible-playbook, par exemple:

ansible-playbook playbook.yml -i inventories/dev/hosts.yml -u user --extra-vars="ansible_become_pass='{{ lookup('env', 'ANSIBLE_BECOME_PASS') }}'"

Bonnes réponses alternatives:

0
JPvRiel

Juste un addenda, afin que personne d'autre ne subisse l'ennui que j'ai eu récemment:

Autant que je sache, la meilleure solution est celle qui suit les lignes générales de toast38coza ci-dessus. S'il est logique de lier statiquement vos fichiers de mots de passe et votre livre de lecture, suivez son modèle avec vars_files (ou include_vars). Si vous voulez les garder séparés, vous pouvez fournir le contenu du coffre-fort sur la ligne de commande comme suit:

ansible-playbook --ask-vault-pass -e@<PATH_TO_VAULT_FILE> <PLAYBOOK_FILE>

Cela est évident rétrospectivement, mais voici les pièges:

  1. Ce sanglant signe @. Si vous le laissez pas, l'analyse échouera silencieusement, et ansible-playbook se déroulera comme si vous n'aviez jamais spécifié le fichier.

  2. Vous devez importer explicitement le contenu du coffre-fort, avec une ligne de commande --extra-vars/-e ou dans votre code YAML. L'indicateur --ask-vault-pass ne fait rien par lui-même (à part vous invite à saisir une valeur qui peut ou non être utilisée ultérieurement).

Puissiez-vous inclure vos "@" et économiser une heure.

0
Eric Anderson

nous pouvons également utiliser EXPECT BLOCK en une fois pour générer et le personnaliser selon vos besoins

- name: Run expect to INSTALL TA
  Shell: |
    set timeout 100
    spawn /bin/sh -i

    expect -re "$ "
    send "Sudo yum remove -y xyz\n"

    expect "$ "
    send "Sudo yum localinstall -y {{ rpm_remotehost_path_for_xyz }}\n"

    expect "~]$ "
    send "\n"

    exit 0
  args:
  executable: /usr/bin/expect
0
Ashish Ranjan

La solution ci-dessus de @ toast38coza a fonctionné pour moi; juste que Sudo: oui est obsolète dans Ansible maintenant. Utilisez pour devenir et pour devenir utilisateur .

tasks:
 - name: Restart Apache service
   service: name=Apache2 state=restarted
   become: yes
   become_user: root
0
Nätu

Très simple, et n’ajoutez que dans le fichier variable:

Exemple:

$ vim group_vars/all

Et ajoutez ceci:

Ansible_connection: ssh
Ansible_ssh_user: rafael
Ansible_ssh_pass: password123
Ansible_become_pass: password123
0
rafaelrms

Après cinq ans, je constate que le sujet est toujours d'actualité. Un peu en miroir de la réponse de leucos que je trouve la meilleure dans mon cas, en utilisant uniquement des outils compatibles (sans authentification centralisée, jetons ou autre). Cela suppose que vous ayez le même nom d'utilisateur et la même clé publique sur tous les serveurs. Si vous ne le faites pas, vous devrez bien sûr être plus spécifique et ajouter les variables correspondantes à côté des hôtes:

[all:vars]
ansible_ssh_user=ansible
ansible_ssh_private_key_file=home/user/.ssh/mykey
[group]
192.168.0.50 ansible_Sudo_pass='{{ myserver_Sudo }}'

ansible-vault create mypasswd.yml
ansible-vault edit mypasswd.yml

Ajouter:

myserver_Sudo: mysecretpassword

Ensuite:

ansible-playbook -i inv.ini my_role.yml --ask-vault --extra-vars '@passwd.yml'

De cette façon, vous n’avez pas à écrire plus de variables pointant vers les mots de passe.

0
Lethargos