web-dev-qa-db-fra.com

Dans Ansible, est-il possible de définir la méthode d'authentification par livre de lecture?

TL; DR: Est-il possible d’enchaîner deux playbooks avec une commande ansible-playbook où un playbook est authentifié par mot de passe et l’autre playbook est authentifié (voir la dernière section pour le but réel).

Installer:

J'ai deux livres de lecture, le second dont includes le premier.

PlaybookA.yml

---
- name: PlaybookA # requires password authentication
  hosts: sub.domain.ext
  remote_user: root
  roles:
    - { role: role1, Sudo: yes }
...

PlaybookB.yml

---
- name: Run PlaybookA
  include: PlaybookA.yml

- name: PlaybookB # requires ssh-key authentication
  hosts: sub.domain.ext
  remote_user: ansible
  roles:
    - { role: role2, Sudo: yes }
...

Exigences:

  1. N'exécutez qu'une seule commande.
  2. Utilisez le mot de passe authentifié pour PlaybookA.
  3. Utilisez ssh-key auth pour PlaybookB.

Question 1:

Est-il possible avec Ansible (versions 1.9.4 ou inférieure) d’exécuter une commande ansible-playbook permettant d’exécuter PlaybookB avec succès en utilisant l’authentification ssh-key, mais lorsque PlaybookB inclut PlaybookA, exécutez PlaybookA en utilisant l’authentification par mot de passe?

Question 2:

Si cela n’est pas possible avec Ansible 1.9.4 ou une version inférieure, est-ce possible avec 2.0.0+?

Notes de valeur:

  1. Ansible fournit --ask-pass (ou -k) en tant que commutateur de ligne de commande permettant l'authentification par mot de passe.
  2. Ansible fournit ask_pass en tant que variable, mais il semble que cela ne puisse être défini que dans ansible.cfg (je n'ai pas été en mesure de définir cela comme une variable de livre de lecture avec l'effet souhaité).
  3. Si vous tentez de définir ask_pass en tant qu’instruction dans un livre de lecture, vous obtenez les éléments suivants: ERROR: ask_pass is not a legal parameter of an Ansible Play. Si ce paramètre était légal, il fournirait un moyen d’indiquer à chaque fois quelle méthode d’authentification utiliser.

But/Monde Réel:

J'essaie de créer un flux de travail de gestion de configuration avec Ansible qui soit suffisamment simple pour que d'autres personnes au travail puissent y apprendre/s'y adapter (et, espérons-le, utiliser Ansible en général pour la CM et l'orchestration).

Pour toute nouvelle machine (VM ou physique) construite, je souhaite exécuter deux playbooks immédiatement. PlaybookA (comme indiqué ci-dessus) a la responsabilité de se connecter avec le bon utilisateur par défaut (dépend généralement de l'infrastructure [aws, vsphere, none, etc.]). Une fois dedans, son travail très limité est de:

  1. Créez l'utilisateur standardisé pour que ansible puisse s'exécuter en tant que (et installez sa clé ssh).
  2. Supprimez tous les utilisateurs non root pouvant exister (artefacts de l'infrastructure VM, etc.).
  3. Désactiver l'accès root.
  4. Désactiver l'authentification par mot de passe (ssh-key uniquement à partir de ce moment).

Selon l'infrastructure vm (ou son absence), l'utilisateur par défaut ou la méthode d'authentification par défaut peut être différent. Dans le but d'adopter Ansible, j'essaie de garder les choses extrêmement simples pour mes collègues, alors j'aimerais automatiser autant que possible ce contrôle de flux.

Une fois que PlaybookA a verrouillé la machine virtuelle et configuré l'utilisateur normalisé, PlaybookB l'utilise pour effectuer toutes les autres opérations nécessaires pour amener notre machine virtuelle au niveau de base requis d'outils et d'utilitaires, etc.

Tous les conseils, astuces, suggestions seraient grandement appréciés.

8
Informatician

J'ai été confronté au même problème aujourd'hui. Deux idées peuvent vous aider: Vous pouvez demander le mot de passe en utilisant vars_Prompt dans votre Playbook au lieu de --ask-pass Définissez le mot de passe en utilisant set_fact:


- name: "set password for the play"

  set_fact: ansible_ssh_pass="{{ my_pass }}"

Vous pouvez stocker le mot de passe dans un fichier, ou demander, comme dans l'exemple ci-dessous. Dans mon exemple, la configuration sshd qui est créée interdira les connexions par mot de passe, mais en utilisant ansible, vous serez étonné que le deuxième manuel soit toujours exécuté (!), Même si j’ai "oublié" de créer une authorised_key. C’est parce qu’annible utilise les options ControlPersist de ssh et maintient simplement la connexion entre les tâches simples. Vous pouvez désactiver cela dans ansible.cfg

Exemple Playbook:


- name: "MAKE BARE: Run preparatory steps on a newly acquired server"
  hosts: blankee

  tasks:
    - name: "set password for the play"
      set_fact: ansible_ssh_pass="{{ my_pass }}"

    - name: "Create directory {{ pathsts }}/registry/ansible-init"
      file: name="{{ pathsts }}/registry/ansible-init" state=directory owner=root group=www-data mode=770

    - name: "copy sshd config file"
      copy:
        src:    'roles/newhost/files/sshd_config'
        dest:   '/etc/ssh/sshd_config'
        owner:  'root'
        group:  'root'
        mode:   '0644'


    - name: "Check syntax of sshd configuration"
      Shell: sshd -t
      register: result
      changed_when: false
      failed_when: "result.rc != 0"

    - name: "Restart SSHD and enable Service to start at boot"
      service: name=sshd state=restarted
      changed_when: false

  vars:
    my_pass2: foobar

  vars_Prompt:
    - name: "my_pass"
      Prompt: "########## Enter PWD:\n "



- name: "Second run: This should authenticate w/out password:"
  hosts: blankee

  tasks:

    - name: "Create directory {{ pathsts }}/registry/ansible-init"
      file: name="{{ pathsts }}/registry/ansible-init22" state=directory owner=root group=www-data mode=770
6
mulleto

Je ne sais pas comment changer la méthode d'authentification dans la pièce. Je pense que je préférerais exécuter deux playbooks différents en tant que travail Jenkins ou similaire, mais je peux penser à une solution de contournement pure Ansible: au lieu d’inclure le second livre de lecture, vous pouvez obtenir ansible pour exécuter une commande Shell en tant qu’action locale, puis exécuter la commande suivante. commande pour exécuter le deuxième livre de lecture du premier. Voici une preuve de concept approximative:

---
- hosts: all
  vars_files:
    - vars.yml
  tasks:
    - debug: msg="Run your first role here."

    - name: Then call Ansible to run the second playbook.
      local_action: Shell ansible-playbook -i ~/workspace/hosts ~/workspace/second_playbook.yml
      register: playbook_results

    - debug: var=playbook_results.stdout_lines

Voici la sortie:

GATHERING FACTS *************************************************************** 
ok: [vagrantbox]

TASK: [debug msg="Run your first role here."] ********************************* 
ok: [vagrantbox] => {
    "msg": "Run your first role here."
}

TASK: [Then call Ansible to run the second playbook.] ************************* 
changed: [vagrantbox -> 127.0.0.1]

TASK: [debug var=playbook_results.stdout_lines] ******************************* 
ok: [vagrantbox] => {
    "var": {
        "playbook_results.stdout_lines": [
            "", 
            "PLAY [Proof of concept] ******************************************************* ", 
            "", 
            "GATHERING FACTS *************************************************************** ", 
            "ok: [vagrantbox]", 
            "", 
            "TASK: [debug msg=\"This playbook was called from another playbook!\"] *********** ", 
            "ok: [vagrantbox] => {", 
            "    \"msg\": \"This playbook was called from another playbook!\"", 
            "}", 
            "", 
            "PLAY RECAP ******************************************************************** ", 
            "vagrantbox                 : ok=2    changed=0    unreachable=0    failed=0   "
        ]
    }
}

PLAY RECAP ******************************************************************** 
vagrantbox                 : ok=4    changed=1    unreachable=0    failed=0   
0
nikobelia