Explaining the Ansible Sudo

Explaining the Ansible Sudo
Techiio-author
Written by Nilima PaulFebruary 7, 2022
9 min read
Ansible
3 VIEWS 0 LIKES 0 DISLIKES SHARE
0 LIKES 0 DISLIKES 3 VIEWS SHARE
Techiio-author
Nilima Paul

Technology Security Analyst

We will know in this article, what's the Ansible Sudo.

Introduction to Ansible Sudo

The accompanying article gives a blueprint to Ansible Sudo. In Ansible, we work on remote objective machines by utilizing playbooks that have plays and errands. The playbook will run on remote objective machines as the same client as on Ansible regulator machine, except if determined in any case. Yet, there are times when the prerequisite is to run an undertaking as another client on remote objective hubs. In such cases, we want become modules like Sudo, which represents substitute client does. This empowers the far-off client to execute orders as another client or favored client. There are not many different choices in this module that make it more adaptable to utilize.

What is Ansible Sudo?

In Ansible, we can utilize become to make use to Linux framework's sudo include. This makes one client execute orders on the framework as one more client for the snapshot of order execution. There are different ways of informing Ansible regarding the favored client, secret word, and other related choices. These ways incorporate characterizing factors, making sections in the stock record or in the imported documents.

Ansible utilizes boundaries like become_exe, become_flag, become_pass, become_user to accomplish the same.

Given beneath is the detail of such boundaries:

1. become_exe: To set the sudo.

Possible ini entries:

  • [privilege_escalation] executable = sudo
  • [sudo_become_plugin] become_exe = sudo
  • env:ANSIBLE_SUDO_EXE
  • env:ANSIBLE_BECOME_EXE
  • var:ansible_sudo_exe
  • var:ansible_become_exe

2. become_flag: To set options to pass in sudo.

ini entries:

  • [privilege_escalation] become_flags = -H -S -n
  • [sudo_become_plugin] flags = -H -S -n
  • env:ANSIBLE_BECOME_FLAGS
  • env:ANSIBLE_SUDO_FLAGS
  • var:ansible_become_flags
  • var:ansible_sudo_flags

3. become_pass: To set the Password to pass to sudo for sudo user.

ini entries:

  • [sudo_become_plugin] password = value
  • env:ANSIBLE_BECOME_PASS
  • env:ANSIBLE_SUDO_PASS
  • var:ansible_become_pass
  • var:ansible_become_password
  • var:ansible_sudo_pass

4. become_user: To set the sudo user.

ini entries:

  • [privilege_escalation] become_user=root
  • user=root
  • env:ANSIBLE_SUDO_USER
  • env:ANSIBLE_BECOME_USER
  • var: ansible_sudo_user
  • var: ansible_become_user

How does Ansible Sudo work?

To use become methods, we can mention the specific parameters in playbook, in static inventory files or in imported files.

Syntax:

The syntax will be like below when we use it is playbook:

---
-tasks:
....
....
-name: Run a command as nobody command: somecommand become: yes
become_method: su become_user: nobody become_flags: '-s /bin/sh'
....
....

Examples of Ansible Sudo

Given underneath are the models referenced:

Here we have an Ansible control server named ansible-regulator and two controllers has named have one and host-two. We will make playbooks and run Ansible orders on the ansible-regulator hub and see the outcomes on remote hosts.

Example #1

In this model, we have a playbook with content like beneath, here we are running this playbook with root client, yet as we referenced become boundaries in the playbook. We are attempting to run order as ec2-client. In the result we will see that order ran as ec2-client.

Kindly note, this client should exist on track machine, else playbook will fall flat.

Code:

---
-hosts: all
become:
yes
become_user: ec2-user
become_method:
sudo tasks:
-name: here we are chekcing the user id by which command is shell: id
register: id_var
-debug
var: id_var['stdout_lines']

Running this playbook like below:

ansible-playbook ansible_sudo.yaml

Output:

blogpost

Example #2

In this model, we have a playbook with content like beneath, here we are restarting a help utilizing Ansible assistance module with client ec2-client however this client have passages in sudoer document of target machines, so we won't be expected to enter secret key for root client.

Code:

---
-hosts:
all
tasks:
-name: Here we are starting the httpd
service.service:
name: httpd
state: restarted

Running this playbook like below with non-root user named ec2-user:

ansible-playbook ansible_sudo_root.yaml

We get the output like below, where it failed, as the user do not have permission to do the task.

Output:

blogpost

Example #3

In this model, we have a playbook with content like beneath, when we are running this playbook as ec2-client with become boundaries, then, at that point, really we are running straightforward order on remote objective machines as another non-root client named testuser after changing to it. Likewise this client ec2-client have sections in sudoer record of target machines, so we won't be expected to enter secret key for testuser client to change to it.

Code:

---
-hosts: all
gather_facts:
no tasks:
-name: Here we are switching to another user named testuser to run a command shell: whoami
become: yes
become_user:
testuser register:
var_output
-debug:
var: var_output.stdout_lines

Running this playbook like below:

ansible-playbook ansible_sudo_non-root.yaml

We get the output like below where we can see that user identified is the testuser, as we used become parameter to run the command as testuser.

Output:

blogpost

Example #4

In this example, we have a playbook with content like below. Here we are running a simple command from a user named testuser, who do not have any sudo entry in sudoer. We will run the playbook with passing option to ask for password of become user which is ec2-user.

Code:

---
-hosts: all
gather_facts:
no tasks:
-name: Here we are switching to another non-root user to run a command shell: whoami
become: yes
become_user: ec2-user register:
var_output
become_method:
su
-debug:
var: var_output.stdout_lines

Running this playbook like below, note the –ask-become-pass option used in command.

ansible-playbook ansible_sudo_nonroot_to_nonroot.yaml --ask-become-pass

Output:

blogpost

Here we can see that the command ran as ec2-user, because we used become parameter to switch to it and passed password on asking by –ask-become-pass option.

Conclusion

As we found in this article, utilizing become is vital part of involving Ansible in your current circumstance, as on track distant servers, we generally have a few limitations on non-root clients. To conquer this, we want heightened honors for time being, that is just conceivable by sudo techniques.

Ansible
Ansible Sudo
Linux
3 VIEWS 0 LIKES 0 DISLIKES SHARE
0 LIKES 0 DISLIKES 3 VIEWS SHARE
Was this blog helpful?
techiio-price-plantechiio-price-plantechiio-price-plantechiio-price-plantechiio-price-plan
You must be Logged in to comment
Code Block
Techiio-author
Nilima Paul
Technology Security Analyst
Techiio-followerTechiio-followerTechiio-follower
201 Blog Posts
0 Discussion Threads
Trending Technologies
15
Software40
DevOps47
Frontend Development24
Backend Development20
Server Administration17
Linux Administration26
Data Center24
Sentry24
Terraform23
Ansible83
Docker70
Penetration Testing16
Kubernetes21
NGINX20
JenkinsX17
Techiio-logo

Techiio is on the journey to build an ocean of technical knowledge, scouring the emerging stars in process and proffering them to the corporate world.

Follow us on:

Subscribe to get latest updates

You can unsubscribe anytime from getting updates from us
Developed and maintained by Wikiance
Developed and maintained by Wikiance