Sto configurando un server MySQL e voglio che Ansible imposti la mysql-rootpassword durante l'installazione.

Con l'aiuto di Internet ho trovato questa soluzione:

- 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_pwdè una variabile caricata da Ansible Vault. Funziona bene, ma ora sul server ci sono molte righe nel registro:

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

Come posso impedire ad Ansible di scrivere password in chiaro nei file di registro?

Per impedire che un'attività con informazioni riservate venga registrata, in syslog o altro, impostare no_log: true sull'attività:

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

L'esecuzione dell'attività verrà comunque registrata, ma con pochi dettagli. Inoltre, il modulo utilizzato deve supportare no_log, quindi testare i moduli personalizzati.

Vedi Domande frequenti per ulteriori dettagli. Può essere applicato a un intero playbook, tuttavia l'output diventa un po 'sgradevole con "censurato!" messaggi.

Il comportamento osservato sembra essere un bug nel modulo debconf. Ho presentato una segnalazione di bug .

L'utente bcoca su github ha sottolineato che è possibile utilizzare la no_log: truedirettiva nelle attività, che impostano le password, per impedire la registrazione. Questa è una soluzione alternativa, che funziona per me fino a quando il bug non viene risolto.

Ho risolto aggiornando la versione di Ansible alla 1.6.1

sudo pip install ansible==1.6.1

Secondo i documenti Ansible :

log_path

Se presente e configurato in ansible.cfg, Ansible registrerà le informazioni sulle esecuzioni nella posizione designata. Assicurarsi che l'utente che esegue Ansible disponga delle autorizzazioni per il file di registro:

log_path=/var/log/ansible.log 

Questo comportamento non è attivo per impostazione predefinita. Si noti che ansible registrerà, senza questa impostazione, gli argomenti del modulo chiamati al syslog delle macchine gestite. Gli argomenti della password sono esclusi.

Sembra che l'impostazione log_pathsul nodo di controllo comporterà la mancata registrazione dei nodi di destinazione.

C'è un modo migliore di un semplice 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 != ""

Come puoi vedere, devi aggiungere:

ignore_errors: true
no_log: true

E quindi crea l'output del risultato del comando con regex_replace, dove:

USER_VAR - variabile di accesso

PASSWORD_VAR - variabile password

Con questo approccio, non solo nasconderai le password e gli accessi, ma otterrai anche l'output della tua operazione

Questo è un additon alla risposta di TheDESTROS da questo thread:

1. scrivere un modello, che avvolge il comando con un segreto:

involucro-script.sh.j2

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

2. Richiamare lo script wrapper e rimuoverlo immediatamente:

- 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

Hai bisogno di un po 'meno di codice e puoi farti uscire dai comandi nei tuoi registri. C'è solo un avvertimento, se un segreto è nei comandi stdout. Se si desidera evitare il modello esterno, il copymodulo con il parametro contentpotrebbe aiutare a scrivere un piccolo script wrapper al volo.

L' no_log: trueapproccio deve essere utilizzato come ultima risorsa se altri tentativi falliscono perché renderà l'esecuzione del compito totalmente opaca e non avrai idea di quando fallirà.

Le pratiche di sicurezza raccomandano di fornire credenziali da stdin o quando non è possibile utilizzare file di credenziali (o persino eseguibili).

Ecco un esempio su come eseguire un login podman sicuro evitando di esporre la password:

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

Con questo, il segreto non sarà esposto, resultma sarai comunque in grado di vedere l'output del comando.

La maggior parte degli strumenti che richiedono l'accesso implementano uno degli approcci più sicuri menzionati. L'uso delle credenziali sulla CLI nel codice è come avere 123456la password della tua banca.