Ansible Become: Privilege Escalation with sudo, su & runas (Complete Guide)

Ansible's become feature allows you to execute tasks with elevated privileges on remote hosts. Whether you need sudo on Linux or runas on Windows, become is the standard way to escalate permissions in Ansible playbooks.

What is Ansible Become?

The become directive tells Ansible to switch to another user (typically root) when executing a task. It replaces the older sudo and su directives that were deprecated in Ansible 2.6+.

See also: Ansible become: Fix Missing sudo Password & Privilege Escalation (Guide)

Basic Usage

Enable become in a playbook

---
- name: Install packages with privilege escalation
  hosts: all
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present

Enable become for a single task

tasks:
  - name: Read protected file
    ansible.builtin.command: cat /etc/shadow
    become: true

become_user: Switch to a Specific User

By default, become escalates to root. Use become_user to switch to any user:

- name: Run as postgres user
  ansible.builtin.command: psql -c "SELECT version();"
  become: true
  become_user: postgres

- name: Run as application user
  ansible.builtin.shell: ./deploy.sh
  become: true
  become_user: appuser
  args:
    chdir: /opt/myapp

See also: ansible.cfg Configuration File: Complete Settings Reference (Guide)

become_method: Choose Escalation Method

Ansible supports multiple escalation methods:

| Method | Platform | Description | |--------|----------|-------------| | sudo | Linux/Unix | Default, most common | | su | Linux/Unix | Switch user | | runas | Windows | Run as another user | | pbrun | Linux | PowerBroker | | pfexec | Solaris | Profile-based execution | | doas | BSD | OpenBSD privilege escalation | | dzdo | Linux | Centrify DirectAuthorize | | ksu | Linux | Kerberos su |

- name: Use su instead of sudo
  ansible.builtin.command: whoami
  become: true
  become_method: su

become_flags: Custom Sudo Flags

Pass extra flags to the become method:

- name: Preserve environment with sudo
  ansible.builtin.command: env
  become: true
  become_flags: '-E'

- name: Use login shell
  ansible.builtin.command: whoami
  become: true
  become_flags: '-i'

See also: Securely Automate Sudo Passwords in Ansible Playbooks

Configure become in ansible.cfg

Set default become behavior in your ansible.cfg:

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

Configure become in Inventory

Set per-host or per-group become settings:

[webservers]
web1 ansible_host=192.168.1.10 ansible_become=true ansible_become_user=root
[webservers:vars]
ansible_become_method=sudo
ansible_become_pass={{ vault_sudo_pass }}

become with Ansible Vault for Passwords

Store sudo passwords securely with Ansible Vault:

# group_vars/all/vault.yml (encrypted)
ansible_become_pass: !vault |
  $ANSIBLE_VAULT;1.1;AES256
  ...

Run with: ansible-playbook site.yml --ask-vault-pass

Windows become with runas

- name: Install IIS on Windows
  ansible.windows.win_feature:
    name: Web-Server
    state: present
  become: true
  become_method: runas
  become_user: Administrator

Common Errors and Fixes

"Missing sudo password"

# Fix 1: Provide password
ansible_become_pass: "{{ vault_password }}"
# Fix 2: Configure passwordless sudo on target
# /etc/sudoers.d/ansible
# ansible ALL=(ALL) NOPASSWD: ALL

"Failed to set permissions on the temporary files"

# Fix: Set pipelining or use become_flags
[ssh_connection]
pipelining = True

Best Practices

Use become: true at task level, not playbook level, for least privilege Store become passwords in Ansible Vault, never in plaintext Use become_user explicitly — don't assume root Configure passwordless sudo for automation accounts Audit become usage with callback plugins

FAQ

What's the difference between become and sudo in Ansible?

become is the modern, platform-agnostic replacement for the deprecated sudo directive. It supports multiple escalation methods (sudo, su, runas, pbrun) through become_method.

Can I use become with ansible ad-hoc commands?

Yes: ansible all -m command -a "whoami" --become --become-user=root

How do I disable become for a specific task?

Set become: false on the task to override playbook-level become.

Basic become (sudo)

- name: Install package as root
  ansible.builtin.apt:
    name: nginx
    state: present
  become: true

become_user

# Run as specific user
- name: Run as postgres
  ansible.builtin.command: psql -c "SELECT version();"
  become: true
  become_user: postgres

become_method

# Use su instead of sudo
- name: Task with su
  ansible.builtin.command: whoami
  become: true
  become_method: su
# Windows: runas
- name: Run as admin on Windows
  ansible.windows.win_shell: whoami
  become: true
  become_method: runas
  become_user: Administrator

Play-Level become

- hosts: webservers
  become: true
  become_user: root
  tasks:
    - apt: name=nginx
    - service: name=nginx state=started
- name: This task runs as appuser
      command: whoami
      become_user: appuser

ansible.cfg Configuration

[privilege_escalation]
become = false
become_method = sudo
become_user = root
become_ask_pass = false

Inventory Configuration

all:
  vars:
    ansible_become: true
    ansible_become_method: sudo
    ansible_become_user: root
hosts:
    db-server:
      ansible_become_user: postgres
      ansible_become_method: su

Provide sudo Password

# Interactive
ansible-playbook site.yml --ask-become-pass
# In inventory (encrypted)
ansible_become_password: "{{ vault_sudo_pass }}"

Passwordless sudo Setup

- name: Configure passwordless sudo
  ansible.builtin.copy:
    content: "{{ ansible_user }} ALL=(ALL) NOPASSWD: ALL\n"
    dest: "/etc/sudoers.d/{{ ansible_user }}"
    mode: '0440'
    validate: 'visudo -cf %s'
  become: true

become_flags

# Preserve environment
- command: env
  become: true
  become_flags: '-E'
# Login shell
- command: whoami
  become: true
  become_flags: '-i'
# Non-interactive
- command: whoami
  become: true
  become_flags: '-n'

Methods Comparison

| Method | Platform | Command | Use Case | |--------|----------|---------|----------| | sudo | Linux/macOS | sudo | Default, most common | | su | Linux | su | Switch user | | runas | Windows | runas | Windows privilege escalation | | pbrun | Linux | pbrun | PowerBroker | | pfexec | Solaris | pfexec | Solaris RBAC | | doas | OpenBSD | doas | BSD sudo alternative | | dzdo | Linux | dzdo | Centrify | | machinectl | Linux | machinectl | systemd containers |

FAQ

When do I need become?

Any task modifying system files, installing packages, managing services, or accessing other users' files requires become: true.

How do I debug become issues?

ansible-playbook site.yml -vvvv
# Shows exact sudo/su command being executed

Can I become a non-root user?

Yes: become: true + become_user: appuser. Ansible first escalates to root (via sudo), then switches to the target user.

Why does become fail with "sudo: a password is required"?

Either configure passwordless sudo or provide the password via --ask-become-pass or ansible_become_password.

Basic become (sudo)

- hosts: all
  become: true  # All tasks run as root
  tasks:
    - apt: { name: nginx, state: present }
    - service: { name: nginx, state: started }

Per-Task become

- name: Read file (no sudo needed)
  command: cat /etc/hostname
  register: hostname
- name: Install package (needs sudo)
  apt: { name: nginx }
  become: true
- name: Deploy as app user
  copy: { src: config.yml, dest: /opt/myapp/config.yml }
  become: true
  become_user: appuser

become Methods

# sudo (default)
- command: whoami
  become: true
  become_method: sudo
# su
- command: whoami
  become: true
  become_method: su
# runas (Windows)
- win_command: whoami
  become: true
  become_method: runas
  become_user: Administrator
# doas (OpenBSD)
- command: whoami
  become: true
  become_method: doas
# pfexec (Solaris)
- command: whoami
  become: true
  become_method: pfexec

ansible.cfg Configuration

[privilege_escalation]
become = false          # Default: don't escalate
become_method = sudo    # Default method
become_user = root      # Default target user
become_ask_pass = false # Don't prompt for password

Inventory Configuration

[webservers:vars]
ansible_become=true
ansible_become_method=sudo
ansible_become_user=root
ansible_become_password={{ vault_sudo_pass }}

become_user (Run as Different User)

# Run as application user
- command: /opt/myapp/migrate.sh
  become: true
  become_user: myapp
# Run as database user
- command: pg_dump mydb > /tmp/backup.sql
  become: true
  become_user: postgres
# Run as www-data
- template:
    src: index.html.j2
    dest: /var/www/html/index.html
  become: true
  become_user: www-data

Sudoers Configuration

# Deploy sudoers for Ansible
- copy:
    content: |
      deploy ALL=(ALL) NOPASSWD: ALL
    dest: /etc/sudoers.d/ansible
    mode: '0440'
    validate: 'visudo -cf %s'
  become: true

Limited Sudo

# Only allow specific commands
- copy:
    content: |
      deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt-get
    dest: /etc/sudoers.d/ansible-limited
    mode: '0440'
    validate: 'visudo -cf %s'
  become: true

Troubleshooting

# "Missing sudo password"
ansible-playbook site.yml -K  # Prompt for password
# "sudo: a password is required"
# Fix: Add NOPASSWD to sudoers
# "sudo: user not in sudoers"
# Fix: Add user to sudo group
- user: { name: deploy, groups: [sudo], append: true }

become with Blocks

- block:
    - apt: { name: nginx }
    - template: { src: nginx.conf.j2, dest: /etc/nginx/nginx.conf }
    - service: { name: nginx, state: restarted }
  become: true  # Applies to all tasks in block

FAQ

become: true vs ansible_become?

Same thing — become: true in playbook, ansible_become=true in inventory. Playbook wins.

Can I escalate from user A to user B (not root)?

Yes: become: true + become_user: userB. This does sudo -u userB.

become with SSH key auth?

SSH key handles connection. become handles privilege escalation. They're independent — you need sudo/NOPASSWD for the remote user regardless of SSH auth method.

Related Articles

• encrypting variables with Ansible Vault • managing Nginx via Ansible • Ansible inventory groups and variables • managing Windows hosts with Ansible