Fórum Root.cz
Hlavní témata => Server => Téma založeno: Daniel 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.
---
- hosts: app
user: sshuser
tasks:
- name: zapnout sluzbu
service:
state: started
name: app1
become: yes
become_user: appuser
-
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
-
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):
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.