Ansible und administrative Rechte

  • Vielleicht kann mir ja jemand von euch helfen... Ich möchte gerne mit Ansible einige administrative Tasks vereinfachen, jedoch erfordern diese Root Rechte. Der direkte Login als Root via SSH ist aus Sicherheitsgründen sowieso ausgeschlossen. Genauso wenig erlaubt es die Sicherheit, dem unprivilegierten User ohne Passwort volle sudo Rechte zu geben.


    Ich habe mich jetzt etwas durch die Ansible Doku gelesen und bin auf become gestoßen. Aufgrund dessen habe ich meine Hosts Datei etwas angepasst - diese sieht nun so aus:


    Zudem habe ich einen Vault angelegt, welcher so aussieht:

    Code
    proxy_become_pass: password1
    borgbackup_become_pass: password2
    torrent_become_pass: password3
    waf_become_pass: password4
    minecraft_become_pass: password5


    Führe ich nun ansible-playbook test_playbook.yml --ask-vault-pass -e vaulted_vars.yml aus, werde ich nach dem Vault PW gefragt und lande nach einiger Zeit warten in einen Timeout.


    Und genau das verstehe ich nicht - ansible sollte per su den User wechseln, das PW dafür hat er aus dem Vault. Aber... er tut quasi nichts. Mache ich da irgendwo einen Fehler oder so?

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Ich vermute du hast einen Syntax Fehler in deinem Inventory

    Code
    proxy.v199.rz01.nbg.de.domain.de:
      vars:
        ansible_become_pass: "{{ proxy_become_pass }}"

    Das "vars" ist in diesem Fall zuviel. Variablen können direkt als Dict angegeben werden und das entsprechende Flag müsste wohl auch "ansible_become_password" heißen (https://docs.ansible.com/ansib…st/user_guide/become.html).

    Code
    proxy.v199.rz01.nbg.de.domain.de:
      ansible_become_password: "{{ proxy_become_pass }}"
  • Ich vermute du hast einen Syntax Fehler in deinem Inventory

    Code
    proxy.v199.rz01.nbg.de.domain.de:
      vars:
        ansible_become_pass: "{{ proxy_become_pass }}"

    Das "vars" ist in diesem Fall zuviel. Variablen können direkt als Dict angegeben werden und das entsprechende Flag müsste wohl auch "ansible_become_password" heißen (https://docs.ansible.com/ansib…st/user_guide/become.html).

    Code
    proxy.v199.rz01.nbg.de.domain.de:
      ansible_become_password: "{{ proxy_become_pass }}"

    Bruh. Irgendwann ist man halt doch mal betriebsblind. Ich probiere das morgen mal, danke :)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Das "vars" ist in diesem Fall zuviel.

    Falsch, da bekomme ich dann einen "Variable nicht gefunden"-like Fehler. Setze ich es wieder rein, kommt der normale Fehler.

    ansible_become_password

    Ja und Nein - das steht da, aber führt zum selben Ergebnis. Zudem steht es hier so, da anders, ... es hat jedenfalls keinen Einfluss.


    Also tl;dr - löst das Problem leider nicht :(

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • ansible-playbook test_playbook.yml --ask-vault-pass -e vaulted_vars.yml

    Code
    -e, --extra-vars
              set additional variables as key=value or YAML/JSON, if filename prepend with @


    if filename prepend with @


    Außerdem: Unterhalb eines Hostnamens ist vars überflüssig. Das wird nur bei group vars benötigt.

  • if filename prepend with @


    Außerdem: Unterhalb eines Hostnamens ist vars überflüssig. Das wird nur bei group vars benötigt.

    Das wäre es ja... teste ich nachher nochmal, vielleicht ist es das ja wirklich. Irgendwo muss da ja der Wurm drin sein.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Du kannst auch einfach `become: yes` im playbook angeben und gut ist. Aus meiner Sicht gehst du sowieso mit 'nem User via Key-Auth rein der Admin-Dinge macht, dann kann der auch NOPASSWD haben und direkt damit agieren, alles andere klingt nach pain oder login via root..

  • Aus meiner Sicht gehst du sowieso mit 'nem User via Key-Auth rein der Admin-Dinge macht, dann kann der auch NOPASSWD haben und direkt damit agieren, alles andere klingt nach pain oder login via root..

    Ja und Nein. Ich gehe per Key rein, ja das ist richtig. Ich will aber eben nicht, dass mein unpriveligierter User da bereits NOPASSWD all hat (sonst wäre er nicht unpriveligiert), sondern dass da erst ein su - zum root mit einem root Passwort passieren muss, bevor der User Admindinge tut.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Hm, ab da wirds Geschmackssache. Ich sehe keinen Mehrwert hier erst SU an zu fragen, wenn du sowieso der einzige bist der sich einloggt und auch SU machen darf. (Das also kein bounce-user ist). Weil meiner Meinung nach: Sobald einer den Key hat den er nicht haben soll und sich auf das System eingeloggt hat, findet sich schon ein Weg Admin zu erlangen oder alleine schon via "localhost" zugriff viel Müll zu erzeugen. D.h. für mich ist quasi die Maschine kompromittiert wenn jemand soweit kommt. Der Grund dann keinen root zu nehmen wäre eher, dass du nicht automatisch alles mit root machst, solange du kein sudo nutzt (oder 'ne root-shell startest) und dass der Login halt auch nicht direkt mit root erfolgt, also ein Faktor mehr der geraten werden muss. Ansonsten wird der nächste mysql-LOAD FILE, memcached oder sudo exploit nicht weit sein.

  • Hm, ab da wirds Geschmackssache.

    Ich pflichte dem jetzt einfach bei, anstatt hier eine große Diskussion anzustarten. ^^

    Ich kann deine Argumentation nachvollziehen, aber es ist wirklich Geschmackssache.


    Ich glaube der Hinweis von perryflynn hat es jetzt gebracht. Ich kann endlich von Erfolg berichten. :saint:

    Code
    user@proxy:~> ls -l
    insgesamt 0
    drwxr-xr-x 1 user users 0 16. Sep 22:01 bin
    -rw-r--r-- 1 root root  0 23. Sep 10:36 testfile
    user@proxy:~>

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber