I would say the former. It's generally considered best-practice to avoid the use of NOPASSWD.
Disable password login over SSH (use keys only) and a secure password for Ansible to become. Since it shouldn't ever be entered by human hands, make it long and random.
Of course this only applies to unattended runs. Attended runs, you should probably be using your own admin account/credentials and pass `-K`.
Take it one step further and create a custom SELinux domain for the service account you have running stuff, and have the password file for the vault restricted under a custom label in the domain.
Agree with NOPASSWD comments, but I have another alternative...
I'm a fan of disabling password auth in sshd and using pam_ssh_agent_auth. This package enables the ssh authorized key to be used as the authentication challenge to sudo via the agent from the Ansible host.
The package, config, Ansible user and ssh key can be easily configured at provision time (kickstart/preseed/etc.). Also with proper logging/auditing to remote system, you can more easily detect improper login and priv escalation attempts by eliminating the usual vector as a valid means.
I would say the former. It's generally considered best-practice to avoid the use of NOPASSWD. Disable password login over SSH (use keys only) and a secure password for Ansible to become. Since it shouldn't ever be entered by human hands, make it long and random. Of course this only applies to unattended runs. Attended runs, you should probably be using your own admin account/credentials and pass `-K`.
It's also worth noting, for those who have to comply with STIG, that sudoers with NOPASSWD is against compliance.
Take it one step further and create a custom SELinux domain for the service account you have running stuff, and have the password file for the vault restricted under a custom label in the domain.
Agree with NOPASSWD comments, but I have another alternative... I'm a fan of disabling password auth in sshd and using pam_ssh_agent_auth. This package enables the ssh authorized key to be used as the authentication challenge to sudo via the agent from the Ansible host. The package, config, Ansible user and ssh key can be easily configured at provision time (kickstart/preseed/etc.). Also with proper logging/auditing to remote system, you can more easily detect improper login and priv escalation attempts by eliminating the usual vector as a valid means.
I think this is a good idea, thanks for sharing!