Ansible Sudo Password — Secure become

Privilege escalation in Ansible — running tasks as root or another user via sudo — is fundamental to most playbooks. This guide covers every method to handle sudo passwords securely, from interactive prompts to fully automated vault-encrypted approaches.

How Ansible Privilege Escalation Works

Ansible uses the become system for privilege escalation:

- name: Install packages (requires root)
  hosts: webservers
  become: true          # Enable privilege escalation
  become_method: sudo   # Method (default: sudo)
  become_user: root     # Target user (default: root)
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present

Key Directives

These can be set at play, block, task, or role level.

Method 1: Interactive Password Prompt (--ask-become-pass)

The simplest approach — Ansible prompts you for the sudo password at runtime:

# Long form
ansible-playbook site.yml --ask-become-pass

# Short form
ansible-playbook site.yml -K

Pros: Password never stored on disk. Simple to use. Cons: Requires manual input — not suitable for CI/CD or unattended automation.

Note: The older --ask-sudo-pass flag is deprecated. Always use --ask-become-pass or -K.

Method 2: Ansible Vault Encrypted Password

Store the sudo password encrypted with Ansible Vault — the recommended approach for automation:

Step 1: Create an Encrypted Variables File

# Create encrypted file
ansible-vault create group_vars/all/vault.yml

Add the password variable:

# group_vars/all/vault.yml (encrypted)
ansible_become_password: "your_sudo_password_here"

Step 2: Reference in Inventory or Playbook

The variable ansible_become_password is automatically used by Ansible when become: true is set. No additional configuration needed.

Step 3: Run with Vault Password

# Prompt for vault password
ansible-playbook site.yml --ask-vault-pass

# Use a vault password file
ansible-playbook site.yml --vault-password-file ~/.vault_pass

# Use environment variable
export ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass
ansible-playbook site.yml

Per-Host Vault Passwords

For environments where different hosts have different sudo passwords:

inventory/
├── group_vars/
│   └── all/
│       └── vault.yml        # Shared secrets
├── host_vars/
│   ├── web1.example.com/
│   │   └── vault.yml        # web1 sudo password
│   └── db1.example.com/
│       └── vault.yml        # db1 sudo password
└── hosts.yml

# host_vars/web1.example.com/vault.yml (encrypted)
ansible_become_password: "web1_sudo_password"

Method 3: Passwordless Sudo

Configure the target hosts to allow sudo without a password — the cleanest approach for automation:

Configure sudoers on Target Hosts

# /etc/sudoers.d/ansible
deploy ALL=(ALL) NOPASSWD: ALL

Or use Ansible to configure it (bootstrap playbook):

- name: Configure passwordless sudo for deploy user
  hosts: all
  become: true
  tasks:
    - name: Add sudoers file for deploy user
      ansible.builtin.copy:
        content: "deploy ALL=(ALL) NOPASSWD: ALL\n"
        dest: /etc/sudoers.d/deploy
        owner: root
        group: root
        mode: '0440'
        validate: 'visudo -cf %s'

Pros: No password management needed. Clean CI/CD integration. Cons: Slightly less secure — any process running as the deploy user can escalate to root.

Restrict Passwordless Sudo to Specific Commands

For tighter security, limit which commands can run without a password:

# /etc/sudoers.d/ansible
deploy ALL=(ALL) NOPASSWD: /usr/bin/apt, /usr/bin/systemctl, /usr/bin/cp

Method 4: ansible.cfg Configuration

Set defaults in ansible.cfg:

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

[defaults]
# Point to vault password file
vault_password_file = ~/.vault_pass

Method 5: Inventory Variables

Set per-host or per-group in inventory:

[webservers]
web1 ansible_host=192.168.1.10 ansible_become_password="{{ vault_web1_pass }}"
web2 ansible_host=192.168.1.11 ansible_become_password="{{ vault_web2_pass }}"

[webservers:vars]
ansible_become=true
ansible_become_method=sudo

Security Best Practices

Never Do This

# BAD — password in plain text in playbook
- hosts: all
  become: true
  vars:
    ansible_become_password: "mysecretpassword"

# BAD — password in plain text in inventory
[all:vars]
ansible_become_password=mysecretpassword

Always Do This

1. Use Ansible Vault for any stored passwords
2. Use no_log: true on tasks that handle credentials
3. Use passwordless sudo when possible (especially in CI/CD)
4. Rotate passwords regularly
5. Limit sudo scope with sudoers rules
6. Audit sudo usage with /var/log/auth.log or auditd

Protecting Command History

# Clear bash history after running sensitive commands
history -c

# Or prefix with a space (bash default ignores space-prefixed commands)
 ansible-playbook site.yml -e "ansible_become_password=secret"

Common Errors and Fixes

"Missing sudo password"

fatal: [host]: FAILED! => {"msg": "Missing sudo password"}

Fix: Add -K flag, set ansible_become_password, or configure passwordless sudo.

"Incorrect sudo password"

fatal: [host]: FAILED! => {"msg": "Incorrect sudo password"}

Fix: Verify the password. Test manually: ssh user@host then sudo -l.

"sudo: a password is required"

fatal: [host]: FAILED! => {"msg": "sudo: a password is required"}

Fix: The user doesn't have NOPASSWD in sudoers and no password was provided. Use one of the methods above.

become_method Alternatives

If sudo isn't available, Ansible supports other methods:

- hosts: openbsd_servers
  become: true
  become_method: doas

Links

• Ansible Privilege Escalation
• Ansible Connection Details
• Ansible Vault Documentation

Related Articles

• Protecting Sensitive Information with no_log
• Ansible Vault: Encrypt and Decrypt Playbook Files
• How to Install Ansible Step-by-Step
• Ansible Error Handling: blocks rescue always
• How to Fix Ansible Connection Failures
• Ansible Best Practices for Production Environments
• Ansible Tutorial for Beginners

Conclusion

Handling sudo passwords securely is a critical part of any Ansible deployment. For interactive use, --ask-become-pass (-K) is sufficient. For automated pipelines, use Ansible Vault-encrypted passwords or configure passwordless sudo on your managed hosts. Never store passwords in plain text — in playbooks, inventory files, or command-line arguments. Combine become with no_log and Vault for defense-in-depth security.