I need to create a postgresql@[db_service_name].service for systemd on remote hosts. Based on extremely limited access rights on such hosts (due to strict company security policies) the challenge I am facing is that the only way to do this manually is via
This allows to edit a unitfile interactively which then is used to start the service.
I do not have any direct write access to /etc/systemd/system or anything else outside /opt on such remotes.
so, is there any way to get specific values into that unit file via ansible under such circumstances?
How locked down exactly is your sudo access? I'd have thought that
if you can issue "sudo systemctl edit" then you can easily cook up
something that can give you arbitrary access, so this restriction
seems like more of an "honour system", i.e. a determined attacker
who realises they can do "sudo systemctl edit" will not be stopped.
So on that basis maybe they will allow "sudo cat …" also.
Nope. Ansible uses sudo to elevate privileges on Linux. If you don’t have a service account that can sudo, you can’t do this with ansible. Your service account is the “remote_user” that ansible uses to SSH into the machine. The sudoers file must grant this account sudo rights.
It does not have to be passwordless sudo. You can provide a variable ansible_become_password that contains the sudo password. There are many ways to do that. The most secure way would be an ansible vault. This is essentially an encrypted vars file. You provide the vault secret when you run the playbook. On your command line you would do something like this.
The @my_vault.yml tells ansible-playbook to source the my_vault.yml for its extra_vars. The --ask-vault-pass prompts you for the vault secret. Your my_vault.yml file would look like this:
The sudo privileges granted to “remote_user” needs be to be limitless. Execute ALL commands as ALL users. One cannot restrict to executing a single binary like ‘useradd’ because it’s running a module with a random name.
When confronted by a lack of privileges to be able to accomplish certain tasks given to me, I’ve usually resorted to creating a ticket with my ‘resolution’, and escalating to the SysAdmins and let them ‘deal’ with the issue. (Usually limited access on specific servers). If they get enough tickets, the Manager or Director usually takes notice, and either grants specific access or transfers the responsibility to the SysAdmins. (What usually happens shortly thereafter is it gets placed back in my lap, with needed privileges as they SysAdmins are already too busy, which is why it was placed in my lap to begin with…) Either resolution is a win.
system access is granted pretty specific (and pretty limited). The fear is not so much a hacker but our own staff should only be able to execute very specific commands (and creating anything in /etc not bein one of those for a member of the database team) he or she is supposed to execute.
@kevin.shumaker: thks, I was hoping to find away around playing such kind of pingpong, but it looks like there is none, so I’ll have to play along.
I am wondering whether granted limited write access to the postgres user (who is the one executing that TASK) to only write files like postgresql.*.service inside /etc/systemd/system could be a solution. I guess using the template module would be the way to do this.
so based on this I wonder whether this could be achived whether I could identify the local command executed by the template module in order to create the file on the remote. Or is that thinking down the wrong road?
it has turned out that our entire approach creating the postgres service needs to be different and that the different approach provides an editable .env file.
So this was kind of a false alarm, sorry