Nadciąga wieczór, a Ty przygotowujesz żmudne zadania automatyzujące konfigurację serwerów. Oto plan: uruchamiasz ansible-playbook, czekasz na cuda… i bum!. Na ekranie pojawia się złowieszczy komunikat: 
				
					FAILED! => {
  "msg": "Missing sudo password"
}

Zamiast upragnionej automatyzacji – klops. Błąd oznacza, że Ansible potrzebuje hasła sudo, a go nie otrzymał. Jeśli to brzmi znajomo i czujesz, jakby ktoś nagle zatrzasnął przed Tobą drzwi, nie martw się. Poniżej pokazuję, jak wyjść z tej impasowej sytuacji.

Skąd się bierze ten błąd?

By wykonać pewne komendy z uprawnieniami administratora, Ansible musi „podnieść” swoje możliwości, używając mechanizmu become. Gdy nie ma odpowiedniego hasła (o ile wymagany jest prompt sudo), wyświetla komunikat, że go brakuje. Innymi słowy:

  1. Playbook wymaga komendy sudo.

2. Brakuje danych uwierzytelniających (hasło) w konfiguracji.

I tyle – proste, ale potrafi napsuć krwi. Co zatem robić? Prześledźmy cztery popularne rozwiązania, wraz z ich wadami i zaletami.

1. Ustawienie hasła w pliku konfiguracyjnym lub w inwentarzu

Umieszczasz hasło w pliku ansible.cfg – ten plik znajdziesz w /etc/ansible, (sekcja [defaults]) lub bezpośrednio w pliku inwentarza (inventory).  W konfiguracji pliku config.cfg możesz dodać np.:

				
					[defaults]
become_ask_pass = True
Dzięki temu Ansible przy uruchamianiu playbooka poprosi Cię o wpisanie hasła. Możesz też ustawić zmienną ansible_become_password w pliku inwentory albo w playbooku. 
				
					ansible_become_password: "TwojeHasloDoSudo"

Zalety

  • Kontrola – łatwo zrozumieć i zarządzać, bo zmienne są widoczne w jednym miejscu.
  • Integracja z Vaultem – można hasła zaszyfrować przy pomocy Ansible Vault.

Wady

  • Ryzyko bezpieczeństwa – jeśli zapomnisz zaszyfrować hasła, możesz je przypadkiem opublikować.
  • Komplikacje – konieczność utrzymywania osobnych zmiennych lub konfigu w różnych środowiskach.

2. Użycie parametru --ask-become-pass (lub -K) Krótki opis

Przekazujesz hasło ręcznie podczas wywołania polecenia: 
				
					ansible-playbook site.yml --ask-become-pass

Przykład z użyciem -K:

				
					ansible-playbook inventory.yml -K

Wtedy Ansible na żywo spyta Cię o hasło sudo.

Zalety

  • Prostota – nic nie modyfikujesz w plikach, Ansible pyta o hasło i je dostaje.
  • Większe bezpieczeństwo – hasło nie jest nigdzie zapisane.

Wady

  • Powtarzalność – za każdym razem musisz wpisać hasło, co bywa uciążliwe.
  • Problematyczna automatyzacja – gdy chcesz zbudować w pełni zautomatyzowany pipeline, ręczne podawanie hasła nie jest wygodne.

3. Konfiguracja NOPASSWD w pliku sudoers

Modyfikujesz /etc/sudoers tak aby konkretny użytkownik mógł wykonywać komendy sudo bez wprowadzania hasła.

Przykładowo:

				
					uzytkownik ALL=(ALL) NOPASSWD:ALL

Zalety

  • Zautomatyzowane wdrożenia – to chyba najwygodniejsze wyjście, jeśli działasz w dużym środowisku DevOps i nie chcesz za każdym razem wpisywać hasła.
  • Oszczędność czasu – brak konieczności pamiętania i wklepywania haseł.

Wady

  • Zmniejszone bezpieczeństwo – jeżeli ktoś przejmie kontrolę nad użytkownikiem, będzie miał pełny dostęp administracyjny.
  • Polityki bezpieczeństwa – wiele organizacji nie pozwala na taką konfigurację.

4. Ansible Vault

Trzymasz hasła w zaszyfrowanych plikach Vaulta (np. group_vars/ lub host_vars/). Ansible automatycznie je odszyfruje przed użyciem, o ile zna klucz Vault.

Przykład:

  1. Tworzenie pliku z tajnymi danymi:
				
					ansible-vault create haslo.yml
Po wywołaniu tego polecenia zostaniesz poproszony o ustawienie hasła do zaszyfrowania pliku. Następnie otworzy się edytor, w którym możesz wpisać np.: 
				
					secret_var: "TwojeHasloHasloSudo"

Zapisz i wyjdź z edytora.

2. Korzystanie z pliku w playbooku:

				
					---
- name: Test vault usage
  hosts: all
  vars_files:
    - haslo.yml
  tasks:
    - name: Echo secret
      debug:
        msg: "Hasło brzmi: {{ secret_var }}"
Dzięki temu, jeśli odpalimy nasz playbook: 
				
					ansible-playbook inventory.yml --ask-vault-pass
Ansible poprosi o hasło, które ustaliliśmy podczas tworzenia secrets.yml, a następnie poprawnie wyświetli (lub wykorzysta) zaszyfrowaną wartość.

Podsumowanie

Gdy Ansible wyrzuca komunikat „Missing sudo password”, nie pozostaje nam nic innego, jak dać mu to, czego potrzebuje. Sposób postępowania zaś zależy w głównej mierze od Twojego modelu bezpieczeństwa i skali środowiska:

  • Małe projekty / testy: Świetnie sprawdzi się –ask-become-pass.
  • Rozbudowane systemy / CI/CD: Zdecydowanie warto rozważyć NOPASSWD lub Ansible Vault.

Pamiętaj, że mądra automatyzacja jest jak dobry poeta – może ułatwić i dodać kolorytu Twojej codzienności, lecz by jej siła w pełni wybrzmiała, musisz zadbać o odpowiednie środki bezpieczeństwa. Nie chowaj więc głowy w piasek. Zabezpiecz swoje hasła, skonfiguruj Ansible tak, by nie sprawiało kłopotów, i pędź ku kolejnym przygodom w świecie DevOps!

Niech to będzie Twój przewodnik w chwilach zwątpienia. Gdy znów ujrzysz ten czerwony napis błędu, pomyśl o poetach, co niegdyś walczyli z mocą słowa. Ty masz potęgę automatyzacji, która – dobrze opanowana – rozwiąże niejeden supeł w Twojej pracy. Powodzenia!