Konfiguruję serwer MySQL i chcę, aby Ansible ustawił mysql-roothasło podczas instalacji.

Przy pomocy Internetu wymyśliłem to rozwiązanie:

- 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_pwdto zmienna ładowana z Ansible Vault. Działa to dobrze, ale teraz na serwerze jest wiele wierszy w dzienniku:

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

Jak mogę powstrzymać Ansible przed zapisaniem haseł w postaci jawnego tekstu w plikach dziennika?

Aby zapobiec logowaniu zadania z poufnymi informacjami, w syslog lub innym, ustaw dla zadania no_log: true:

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

Uruchomienie zadania będzie nadal rejestrowane, ale z drobnymi szczegółami. Ponadto używany moduł musi obsługiwać no_log, więc przetestuj moduły niestandardowe.

Aby uzyskać szczegółowe informacje, zobacz Ansible FAQ . Można go zastosować do całego podręcznika, ale wynik jest nieco nieprzyjemny z „ocenzurowaną!” wiadomości.

Obserwowane zachowanie wydaje się być błędem w module debconf. Złożyłem raport o błędzie .

Użytkownik bcoca w github zwrócił uwagę, że no_log: truedyrektywy można używać w zadaniach, które ustawiają hasła, aby zapobiec rejestrowaniu. Jest to obejście, które działa dla mnie, dopóki błąd nie zostanie naprawiony.

Rozwiązałem problem, aktualizując wersję Ansible do wersji 1.6.1

sudo pip install ansible==1.6.1

Zgodnie z dokumentami Ansible :

ścieżka_dziennika

Jeśli jest obecny i skonfigurowany ansible.cfg, Ansible będzie rejestrować informacje o wykonaniach w wyznaczonym miejscu. Upewnij się, że użytkownik uruchamiający Ansible ma uprawnienia do pliku dziennika:

log_path=/var/log/ansible.log 

To zachowanie nie jest domyślnie włączone. Zauważ, że ansible, bez tego ustawienia, zapisuje argumenty modułu wywoływane w syslog zarządzanych komputerów. Argumenty hasła są wykluczone.

Wygląda na to, że ustawienie log_pathw węźle kontrolnym spowoduje, że dzienniki w węzłach docelowych nie będą mieć.

Jest lepszy sposób niż tylko 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 != ""

Jak widać, musisz dodać:

ignore_errors: true
no_log: true

Następnie wykonaj wynik polecenia za pomocą regex_replace, gdzie:

USER_VAR - zmienna logowania

PASSWORD_VAR - zmienna hasła

Dzięki takiemu podejściu nie tylko ukryjesz hasła i loginy, ale również uzyskasz wyniki swojej operacji

To jest dodatek do odpowiedzi TheDESTROS z tego wątku:

1. napisz szablon, który otoczy komendę sekretem:

wrapper-script.sh.j2

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

2. Wywołaj skrypt opakowania i usuń go od razu:

- 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

Potrzebujesz trochę mniej kodu i możesz wykonać standardowe polecenia w dziennikach. Jest tylko jedno zastrzeżenie, jeśli sekret jest w stdout poleceń. Jeśli chcesz uniknąć szablonu zewnętrznego, copymoduł z parametrem contentmoże pomóc w napisaniu małego skryptu opakowania w locie.

no_log: truePodejście ma być używany jako ostatniej instancji, jeżeli inne próby nie powiodą się, ponieważ dzięki niej będzie wykonanie zadania całkowicie nieprzezroczysty i nie masz pojęcia, kiedy zawodzą.

Praktyki bezpieczeństwa zalecają podawanie poświadczeń ze standardowego wejścia lub, gdy nie jest to możliwe, przy użyciu plików poświadczeń (lub nawet plików wykonywalnych).

Oto przykład, jak wykonać bezpieczne logowanie podmana, unikając ujawnienia hasła:

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

Dzięki temu sekret nie zostanie ujawniony, resultale nadal będziesz mógł zobaczyć wynik polecenia.

Większość narzędzi wymagających logowania wykorzystuje jedno z bardziej bezpiecznych wymienionych podejść. Używanie poświadczeń w interfejsie CLI w kodzie jest jak 123456hasło w banku.