Je configure un serveur MySQL et souhaite qu'Ansible définisse le mysql-rootmot de passe lors de l'installation.

Avec l'aide d'Internet, j'ai trouvé cette solution:

- name: Set MySQL root password before installing
  debconf: name='mysql-server' question='mysql-server/root_password' value='{{mysql_root_pwd | quote}}' vtype='password'
- name: Confirm MySQL root password before installing
  debconf: name='mysql-server' question='mysql-server/root_password_again' value='{{mysql_root_pwd | quote}}' vtype='password'
- name: Install Mysql
  apt: pkg=mysql-server state=latest

mysql_root_pwdest une variable chargée à partir du coffre-fort Ansible. Cela fonctionne bien, mais maintenant sur le serveur il y a beaucoup de lignes dans le journal:

Apr 10 14:39:59 servername ansible-debconf: Invoked with value=THEPASSWORD vtype=password question=mysql-server/root_password name=mysql-server unseen=None
Apr 10 14:39:59 servername ansible-debconf: Invoked with value=THEPASSWORD vtype=password question=mysql-server/root_password_again name=mysql-server unseen=None

Comment puis-je empêcher Ansible d'écrire des mots de passe en texte clair dans les fichiers journaux?

Pour empêcher une tâche contenant des informations confidentielles d'être journalisée, dans syslog ou autre, définissez no_log: true sur la tâche:

- name: secret stuff
  command: "echo {{secret_root_password}} | sudo su -"
  no_log: true

L'exécution de la tâche sera toujours enregistrée, mais avec peu de détails. De plus, le module utilisé doit prendre en charge no_log, alors testez les modules personnalisés.

Voir la FAQ Ansible pour plus de détails. Il peut être appliqué à un playbook entier, mais la sortie devient un peu désagréable avec "censuré!" messages.

Le comportement observé semble être un bogue dans le module debconf. J'ai déposé un rapport de bug .

L'utilisateur bcoca de github a souligné que l'on peut utiliser la no_log: truedirective dans les tâches, qui définissent les mots de passe, pour empêcher la journalisation. Ceci est une solution de contournement, qui fonctionne pour moi jusqu'à ce que le bug soit corrigé.

J'ai résolu en mettant à niveau la version Ansible vers 1.6.1

sudo pip install ansible==1.6.1

Selon les documents Ansible :

log_path

S'il est présent et configuré dans ansible.cfg, Ansible enregistrera des informations sur les exécutions à l'emplacement désigné. Assurez-vous que l'utilisateur exécutant Ansible dispose d'autorisations sur le fichier journal:

log_path=/var/log/ansible.log 

Ce comportement n'est pas activé par défaut. Notez qu'ansible enregistrera, sans ce paramètre, les arguments du module appelés dans le syslog des machines gérées. Les arguments de mot de passe sont exclus.

Cela ressemble à un réglage log_pathsur votre nœud de contrôle, car il n'aura pas de journaux sur les nœuds de destination.

Il y a un meilleur moyen que juste no_log: True

- name: write in string variables login and password
  set_fact:
    temp_user: "{{ USER_VAR }}"
    temp_pass: "{{ PASSWORD_VAR }}"


- name: Your operation with password in output
  shell: '/opt/hello.sh'
  ignore_errors: True
  no_log: True
  register: myregister

- debug:
    msg: '{{ myregister.stderr | regex_replace(temp_user) | regex_replace(temp_pass) }}'
  when: myregister.stderr != ""

- debug:
    msg: '{{ myregister.stdout | regex_replace(temp_user) | regex_replace(temp_pass) }}'
  when: myregister.stdout != ""

- fail:
    msg: "error shell /opt/hello.sh"
  when: myregister.stderr != ""

Comme vous pouvez le voir, vous devez ajouter:

ignore_errors: true
no_log: true

Et puis faites la sortie du résultat de la commande avec regex_replace, où:

USER_VAR - variable de connexion

PASSWORD_VAR - variable de mot de passe

Avec cette approche, vous masquerez non seulement les mots de passe et les connexions, mais obtiendrez également le résultat de votre opération

Ceci est un complément à la réponse de TheDESTROS de ce fil:

1. écrire un modèle, qui enveloppe la commande avec un secret:

wrapper-script.sh.j2

echo {{ secret_eg_from_ansible_vault }} | su - "ls -l"

2. Appelez le script wrapper et supprimez-le immédiatement:

- name: create template
  template:
    src: wrapper-script.sh.j2
    dest: /tmp/wrapper-script.sh
    mode: 0700
  no_log: True
- name: invoke command with secret and remove it
  shell: /tmp/wrapper-script.sh; rm -f /tmp/wrapper-script.sh

Vous avez besoin d'un peu moins de code et vous pouvez ignorer les commandes de vos journaux. Il n'y a qu'une seule caveeat, si un secret est dans les commandes stdout. Si vous voulez éviter le modèle externe, le copymodule avec le paramètre contentpeut aider à écrire un petit script wrapper à la volée.

L' no_log: trueapproche doit être utilisée en dernier recours si d'autres tentatives échouent car cela rendra l'exécution de la tâche totalement opaque et vous n'aurez aucune idée de l'échec.

Les pratiques de sécurité recommandent de donner des informations d'identification à partir de stdin ou lorsque cela n'est pas possible en utilisant des fichiers d'informations d'identification (ou même des exécutables).

Voici un exemple sur la façon d'effectuer une connexion podman sécurisée en évitant d'exposer le mot de passe:

- name: secured login
  become: true
  command: >
    podman login --username={{ user }} --password-stdin ...
  args:
    stdin: "{{ secret }}"
  register: result

Avec cela, le secret ne sera pas dévoilé, resultmais vous pourrez toujours voir la sortie de la commande.

La plupart des outils nécessitant une connexion mettent en œuvre l'une des approches les plus sécurisées mentionnées. L'utilisation des informations d'identification sur CLI dans le code est comme avoir 123456comme mot de passe bancaire.