Explain Privilege Escalation in Ansible

Ansible configuration file contain set of sections(sections can be identified by square brackets [blah blah] ). Each section contain different sort of configurations. Here I am going to explain the section called privilege scalation for basic operations.

Easiest way to grab default privilege escalation setting are from above Linux grep command (after 5 lines of search pattern in config file).

[privilege_escalation]
#become=True
#become_method=sudo
#become_user=root
#become_ask_pass=False

We need to know how default section works to understand the privilege escalation. Hence here the default section for basic operations

[default]
inventory=/etc/ansible/hosts
remote_user=root

Above the default configuration, but to keep highly secure our Ansible Configuration node, it need to protect from outside attacks. One of main thing would be change remote_user. That need to change into some other user name who have enough sudo privileges to become into different user to perform administrative work. Then no one from out side able to guess the username (if its root any knows Linux machines has a user called root).

[default]
inventory=/etc/ansible/hosts
remote_user=devops

This would be a better than above. Okay now lets see how this works during ansible executions.

cat /etc/ansible/ansible.cfg

[defaults]
inventory = inventory
remote_user = devops
[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

[defaults]

This section knows how Ansible Control nodes connect to Manage Nodes (Control Node is Ansible Master Node and Manage node is where your applications hosted).

To connect to MN (Manage Nodes) , CN (Control Node) should know about MNs ip addresses/hostnames. In ansible we have a file/files called inventory where is contain MNs ip’s or hostnames. So that should be linked into ansible config file under inventory parameter.

Then CN need to know from which user I should connect to MN.

Pre-prerequisites:

• We should create a user called “devops” in all MNs.
• Password-less ssh connection from CN to MN. (to minimize overhead of typing password every time)

That username should mentioned inside ansible cfg file under “remote_user”. So now our ansible config file looks like below.

[defaults]
inventory = inventory
remote_user = devops

Now CN can connect (ssh) to MN as above, since CN now has all necessary details to ssh to MN.

Okay, now we need to install or perform administrative tasks inside MN. But devops user doesn’t has enough privileges to do.

[privilege escalation]

Pre-prerequisites:

• We need to configure sudo access to devops user (all commands without password) in MN.

How we become into root from devops user in servera (MN).

devops@servera:~$ sudo su -

root@servera:~#

So above process should be automatically perform by ansible before doing any kind of administrative work ( installation packages, remove packages, update /etc/ files, change file permissions, create/delete users, create/delete files directories links..etc).

Hence above process in mentioned under [privilege escalation], “how privilege should grant from remote_user to perform admin work”.

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

become_method=(how to switch into another user. eg: su, su-, sudo)

become_user=(to which user need to be switched)

become-ask_pass=(does it need to get pw while switching user)

become=(True will enable whole “become_” parameters, False will disable whole “become_” parameters).

Finally this is how our ansible.cfg looks like below.

[defaults]
inventory = inventory
remote_user = devops
[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

Hope this explanation gives you clear and better understanding about the privilege escalation section in ansible.cfg file.

Conclusion

Finally, ansible.cfg configurations are very important. Knowing about how privilege works can keep your entire nodes secure from unauthorizes access from Control Node. Since CN has full control over ssh to all nodes, it is must to keep CN in highly secure manner to avoid any attacks.

Please comment if you see anything need to be change or correct.

Thank you for reading.