Ansible privilege escalation using ‘sudo su -‘

Recently I wrote an Ansible playbook to extract data from an Informatica PowerCenter repository. The data was then compressed and uploaded into Nexus Repository Manager. I used the command line utility, pmrep, to execute the commands needed to connect to the Informatica repository and to extract the data. A specific Informatica user had been given the necessary privileges to execute the pmrep commands.

NOTE: To become the Informatica user, the following command was used:

sudo su – informatica-user

Ansible Become Directives

I was able to leverage Ansible’s privilege escalation functionality, Become, to execute the commands from my Ansible playbook. The Become directives allow you to execute tasks within a playbook using a different user than the user logged into the machine. There are a few locations the become directives can be set ranging from the playbook down to the task level. Not every task in my playbook needed privilege escalation, but the tasks that did had the following directives defined:

remote_user: remote-user
become: yes
become_user: informatica-user
become_method: su

remote_user

The remote user directive defines the user that will be logging into the Informatica PowerCenter server.

become

When set to yes the become directive activates privilege escalation for the task.

become_user

The become user directive defines who the user will ‘become’ when executing the task. I set this directive to the Informatica user that had been given the necessary privileges to execute pmrep commands.

become_method

The become method directive defines which privilege escalation tool (sudo, su, pbrun, pfexec, doas, dzdo, ksu, runas, machinectl) to use when becoming the new user. I chose ‘su’ since the command to switch users on the Informatica server was

sudo su – informatica-user

Fingers Crossed

I ran my playbook expecting perfection but was met with the following error when my first task using privilege escalation was executed:

{“failed”: true, “msg”: “ERROR! Timeout (12s) waiting for privilege escalation prompt: “}

Naturally I went to my most trusted resource, the internet, where I found several suggestions to increase the timeout. I increased the timeout, but unfortunately it just increased the time it took me to see the following:

{“failed”: true, “msg”: “ERROR! Timeout (40s) waiting for privilege escalation prompt: “}

I quickly tried changing the become_method directive to use ‘sudo’, with no success. It did not take long before I was consulting with my most trusted resource again.

Jackpot!

After some research I came across something that looked promising. A suggestion to set the following environment variable:

ANSIBLE_BECOME_EXE=’sudo su -‘

This directive defines which executable to use for privilege escalation. I reset the become_method directive to ‘su’, added the environment variable to my Ansible playbook command, hit enter, and… The perfection I had been waiting for! The tasks using privilege escalation executed successfully, logging into the Informatica server and switching to the Informatica user.

The executable to use for privilege escalation can also be set in Ansible’s configuration file, ansible.cfg by entering the following:

[privilege_escalation]
become_exe=’sudo su -‘

While I did not lose all day trying to figure this out, it did take some time and head scratching.