Ansible - složitější privilegia

Daniel

Ansible - složitější privilegia
« kdy: 21. 11. 2018, 20:49:16 »
Ahoj,

řeším takovou záležitost s eskalací privilegií s Ansible. Mám třeba playbook pro zapnutí serivce. Na serveru mám uživatele pro SSH přístup, "sshuser". Ten má právo přes sudo eskalovat na aplikační účet (sudo su - appuser). A nakonec "appuser" může přes sudo zastavit nebo spustit servicu dané aplikace (sudo systemctl start app1.service).

Mám nějaký základní (nefungující) playbook.
Kód: [Vybrat]
---
- hosts: app
  user: sshuser
  tasks:
     - name: zapnout sluzbu
       service:
          state: started
          name: app1
       become: yes
       become_user: appuser



Re:Ansible - složitější privilegia
« Odpověď #1 kdy: 22. 11. 2018, 01:11:58 »
Kdyz se podivam na aktualni dokumentaci, tak se tam vicenasobne pouziti become nikde nezminuje a ani jsem to jinde nenasel. Takze nejspis zbyvaji dve moznosti:
  • pripojovat se s Ansible na SSH toho aplikacniho uzivatele
  • upravit /etc/sudoers tak aby mohl i ten stavajici uzivatel s pomoci sudo restartovat sluzbu

jméno

Re:Ansible - složitější privilegia
« Odpověď #2 kdy: 23. 11. 2018, 09:52:47 »
Toto jsem před pár dny řešil a došel jsem k názoru, že v Ansible použít jakékoliv moduly s přesně definovaným sudoers nejde. Ansible totiž ve většině případů funguje tak, že na server nauploadouje vlastní python skript, který se potom spouští. Takže výsledný příkaz, který se spustí na systému vypadá při použití become třeba takto (je tam přímo hláška ze sudo):

Kód: [Vybrat]
Sorry, user xxx is not allowed to execute '/bin/sh -c echo BECOME-SUCCESS-vhtkwdodhwmljovxaktortaloznjpoku; /usr/bin/python /opt/whatever/.ansible/tmp/ansible-tmp-1542799062.64-151971256696254/command.py; rm -rf \"/opt/whatever/.ansible/tmp/ansible-tmp-1542799062.64-151971256696254/\" > /dev/null 2>&1' as root on hostname-xxx.
Moje řešení tedy bylo použív v Playbooku modul command, který posílá přímo celý příkaz 'sudo systemctl restart nazev-sluzby'. Tam je problém, že je nutné pak dělat znovu logiku, kterou jinak dělá modul service pomocí when, tj. různé příkazy podle verze systému (např. systemctl pro CentOS >= 7 a service pro CentOS <= 6).

Pokud by účet appuser měl sudo na všechny příkazy, tak by to fungovalo standartní cestou.