allowing user to run playbook without giving them password

I have an ansible playbook that I would like to allow a regular user to run to install an application on a centos server, but I don't necessarily want to give them the login credentials. I know you can use ansible vault to store encrypted data, but from what I can tell, you can also decrypt this data pretty easily. Any ideas on if this is possible and how to achieve it?


Solution 1:

Most methods of installing software require a privilaged user.

Least privilage and accountability principles imply logins should be with a less-privilaged personal user, and be granted privilaged where necessary. Ansible can help with become plugins that run things as another user for you, with doas or sudo or whatever.

Passwords are a garbage auth method in general. Low entropy, poor practices historically, and inconvenient to automate. Some run as another user methods ask for your personal password, which reduces the need for shared credentials. Ansible can prompt the user for such a password with --ask-become-pass

ansible-vault (and security system lookup plugins) only protect data at rest, not when in use. The person running Ansible will have access to the plaintext secret. It may be visible with verbose enough debugging enabled.

Given all the above, a decent solution might be configuring become without passwords. ssh in using a key or certificate, but use become to run a package task as root. However, what they do as root cannot be restricted. Ansible generates temporary scripts to run modules, and there is no good sudo rule to restrict commands that look like /bin/sh -c '/usr/bin/python3 ~/.ansible/tmp/ansible-tmp-1628781435.871488-116497-130276452381107/AnsiballZ_setup.py'

Run privilaged playbooks for users. Encourage them give input on what to do, but do not give them credentials to do it. Put such playbooks in version control and accept change requests. Run the plays however you like:

  • ansible-runner scheduled in cron.
  • From a pipeline triggered by merges to the production branch in version control.
  • Jobs run from an AWX user interface.