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.
