About Become Password

Our lab’s passwordless sudo has meant never needing a become password so far — a genuine luxury most real environments don’t have. This chapter covers supplying one properly, and a real trap where escalation interacts with delegate_to.

--ask-become-pass: Prompting For The Escalation Password

Many real environments require an actual password to escalate, rather than our lab’s NOPASSWD setup. Prompt for it interactively:

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

Storing A Become Password: ansible_become_password And Vault

For automation, an interactive prompt isn’t viable — the exact same reasoning behind the vault section’s --ask-vault-pass versus --vault-password-file distinction. ansible_become_password can be set as a variable — and, per that entire section, it should be vault-encrypted anywhere it’s actually stored:

# secrets.yaml (vault-encrypted)
ansible_become_password: "supersecret"

- name: My Play
  hosts: servers
  become: true
  vars_files:
    - secrets.yaml
  tasks:
    - name: Install a package
      ansible.builtin.package:
        name: curl
        state: present

A become password is exactly the kind of secret the entire vault section exists to protect — this is a direct, natural application of everything covered there.

Where Escalation Actually Happens: The Managed Host, Not The Control Node

become: true escalates privileges on whichever host the task actually executes on. For an ordinary task, that’s the remote managed host — unsurprising. This becomes genuinely important the moment delegate_to enters the picture.

The delegate_to Interaction: A Real Gotcha

Recall delegate_to from the previous section: a delegated task executes on the delegated host, not the originally-targeted one — and its become escalation follows the execution, not the original target. This creates a genuine, well-known trap: if a play sets become: true at the play level, and a task delegates to localhost, Ansible will try to escalate privileges on your own control node for that task — very likely not what you intended, and potentially prompting for your own local sudo password, or failing outright if you don’t have sudo configured there at all.

A Concrete Demonstration

- name: My Play
  hosts: servers
  become: true
  tasks:
    - name: Log locally (accidentally inherits become: true!)
      ansible.builtin.debug:
        msg: "Logging from control node"
      delegate_to: localhost

Since become: true is set at the play level, it applies to every task — including this delegated one, meaning Ansible attempts to escalate privileges on the control node itself for this specific task, not on any remote server.

The fix is an explicit override on the delegated task:

    - name: Log locally (correctly runs without escalation)
      ansible.builtin.debug:
        msg: "Logging from control node"
      delegate_to: localhost
      become: false

become: false, set explicitly on the delegated task, overrides the inherited play-level become: true specifically for this one task — worth treating as a required pairing anywhere delegate_to: localhost meets a higher-level become: true, given how common that combination genuinely is.

Best Practices

• Avoid --ask-become-pass for anything beyond occasional manual runs — use a vault-encrypted ansible_become_password for automation, exactly like protecting any other secret.
• Always explicitly set become: false on a delegate_to: localhost task whenever become: true is active at a higher level — don’t assume it’s harmless just because the task itself looks simple.
• Remember become always applies to wherever a task actually executes — for a delegated task, that’s the delegated host, never the one the play is nominally iterating over.