Estou configurando um servidor MySQL e quero que o Ansible defina a mysql-rootsenha durante a instalação.

Com a ajuda da internet, eu vim com esta solução:

- 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é uma variável carregada do Ansible Vault. Isso funciona bem, mas agora no servidor existem muitas linhas no log:

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

Como posso impedir que o Ansible grave senhas em texto não criptografado nos arquivos de log?

Para impedir que uma tarefa com informações confidenciais seja registrada, em syslog ou outro, defina no_log: true na tarefa:

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

A execução da tarefa ainda será registrada, mas com pequenos detalhes. Além disso, o módulo usado deve suportar no_log, portanto, teste os módulos personalizados.

Consulte Ansible FAQ para mais detalhes. Pode ser aplicado a um manual inteiro, no entanto, a saída fica um pouco desagradável com "censurado!" mensagens.

O comportamento observado parece ser um bug no módulo debconf. Eu enviei um relatório de erro .

O usuário bcoca no github apontou que é possível usar a no_log: truediretiva em tarefas, que definem senhas, para impedir o registro. Esta é uma solução alternativa, que funciona para mim até que o bug seja corrigido.

Eu resolvi atualizando a versão Ansible para 1.6.1

sudo pip install ansible==1.6.1

De acordo com os documentos Ansible :

log_path

Se presente e configurado ansible.cfg, o Ansible registrará informações sobre execuções no local designado. Verifique se o usuário que está executando o Ansible tem permissões no arquivo de log:

log_path=/var/log/ansible.log 

Esse comportamento não está ativado por padrão. Observe que o ansible, sem essa configuração, registra os argumentos do módulo chamados para o syslog das máquinas gerenciadas. Os argumentos da senha são excluídos.

Parece que a configuração log_pathno nó de controle resultará em não ter logs nos nós de destino.

Existe uma maneira melhor do que apenas 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 != ""

Como você pode ver, você precisa adicionar:

ignore_errors: true
no_log: true

E, em seguida, faça a saída do resultado do comando com regex_replace, em que:

USER_VAR - variável de login

PASSWORD_VAR - variável de senha

Com essa abordagem, você não apenas ocultará as senhas e logins, mas também obterá o resultado da sua operação

Este é um complemento para a resposta de TheDESTROS a partir deste tópico:

1. escreva um modelo, que agrupe o comando com um segredo:

wrapper-script.sh.j2

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

2. Chame o script do wrapper e remova-o imediatamente:

- 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

Você precisa de um pouco menos de código e pode descobrir os comandos em seus logs. Existe apenas uma caverna, se houver um segredo nos comandos stdout. Se você deseja evitar o modelo externo, o copymódulo com o parâmetro contentpode ajudar a escrever um pequeno script de wrapper rapidamente.

A no_log: trueabordagem deve ser usada como último recurso se outras tentativas falharem, pois tornará a execução da tarefa totalmente opaca e você não terá idéia de quando falhar.

As práticas de segurança recomendam fornecer credenciais do stdin ou, quando não for possível, usar arquivos de credenciais (ou mesmo executáveis).

Aqui está um exemplo de como executar um login podman seguro, evitando expor a senha:

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

Com isso, o segredo não será exposto, resultmas você ainda poderá ver a saída do comando.

A maioria das ferramentas que precisam de login implementam uma das abordagens mais seguras mencionadas. O uso de credenciais na CLI no código é como ter 123456como sua senha do banco.