Ansible become_method behavior and sudoers policy constraints

Privilege Escalation Consistency Across Environments

Ansible uses the become system to manage privilege escalation, defaulting to sudo on Unix-like systems. In local development environments where ansible_connection=local is used, the control node often has a permissive sudoers configuration, such as NOPASSWD, allowing playbooks to execute seamlessly.

Production environments typically implement stricter security policies. Constraints such as requiretty, env_reset, or specific command whitelists in the /etc/sudoers file can cause become operations to fail, even when the playbook logic is identical to the local version.

There is uncertainty regarding the optimal configuration of become_flags (e.g., -H or -i) and the selection between become_method=sudo and become_method=su to ensure compatibility with restrictive production policies without compromising security.

• How do different become_flags impact the execution of commands under a restricted sudoers policy?
• In what scenarios is become_method=su preferable over sudo for production environments with strict terminal requirements?