LOGBOOK

HELP

Quiz Entry - updated: 2026.10.30

Why does Ansible need privilege escalation, and how does it work on RHEL-type systems?

Tasks like installing software need root, but Ansible usually logs in as an ordinary user, so it must "become" root afterwards, by default via sudo. On RHEL 8 and 9, members of the group wheel may use sudo after entering their password.

Control node logs in over SSH as remote_user devops, then sudo switches to become_user root, which runs the module; config keys become, become_method and become_user label the hops

* Log in as an ordinary user, then become root only for the work that needs it. *

Logging in directly as root over SSH is usually disabled for good reason. So Ansible connects as a normal account and then escalates, exactly as an admin would type sudo dnf install httpd:

  • become = true turns escalation on, become_method = sudo picks the mechanism, become_user = root names the target user.
  • Who may use sudo is defined on the managed host in /etc/sudoers. RHEL's default line %wheel ALL=(ALL) ALL lets group wheel run any command as anyone, after typing their own password.
  • To grant extra users or groups sudo rights, drop a file into /etc/sudoers.d/; it must be owned by root, or sudo ignores it.
  • If sudo asks for a password, set become_ask_pass = true so Ansible prompts once at the start.

The commented variant %wheel ALL=(ALL) NOPASSWD: ALL drops the password prompt. That is convenient for automation, but means anyone who gets that account's SSH key is effectively root. Which method to use is a security trade-off each organisation decides for itself.

Go deeper:

From Quiz: ITIA / Ansible Inventory, Configuration and Playbooks | Updated: Oct 30, 2026