Ansible security: Is a user with password-less sudo permissions the way to go?
I'm trying to figure out what the best practices are for running privileged commands with Ansible, and I ran across this upvoted StackExchange answer
The relevant part:
[OP's suggestion] Create a unprivileged user dedicated for Ansible with sudo access / let the Ansible user to run every commands through sudo without specifying any password
[Reply] Exactly. An unprivileged user that you can audit back to ansible, with sudo roles. Ideally, create a standard user dedicated to server-to-server/ansible communications with sudo access (without password).
From what I understand, this is saying it's best to create a user that can run commands with sudo without using a password. However, how is this any different than logging in as the root user?
Posted Jan 25, 2019, 12:42 AM UTC
Logging.
If you log in as root to do the work, all you see in the logs is that someone logged in as root. This may have been you doing ansible work, or it may have been a malicious actor with a compromised key or password. So having a separate account helps with after-the-fact auditing.
Disabling root login over SSH completely also helps a little with security and a little more with compliance.
There are also better ways to secure non-root accounts with other security features (limits, SELinux, permissions, etc.) that don't necessarily apply to the root account.
And if you get really paranoid, it's possible to selectively grant the ansible user sudo privileges to install software and do other things, but prevent them access to user management or interactive root shells. This would allow you to mostly manage your systems with ansible but somewhat limit the possibility that the account could be used maliciously.
Yes, I'd go as far as to say disable password login over ssh completely. Use keys. And sudo can give you really fine control over which commands can be run by a user as root. So limit that to what your plays need.
Any advice on selective permissions? I work in a highly regulated industry and password-less sudo is a compliance failure, as is
ALLpermission insudoers. Unfortunately, ansible re-wraps everything throughshand temporary script files, so specifically allowing, for example,apt-get install ...won't work unless we ignore theaptmodule and go straight to thecommandmodule - which makes Ansible, in those circumstances, mostly an annoying script wrapper. And it makes idempotency a challenge as well.Wait, you're technically not allowed to use sudo at all?!
Edit : never mind, I get it now, you can select but not grant blanket privileges. I'd have to think about that for a while. I suspect you'd need to create an enormous command alias that contains "approved" binaries from /sbin
That's what we do. We have a huge
sudoersfile and we have to use thecommandmodule so that Ansible will pass directly to the underlying system, but then if we need idempotency we have to engineer it ourselves with checks/registers.