Privilege Escalation with become

become is how Ansible runs a task as a different user — almost always root — after connecting over SSH as an unprivileged account. You log in as deploy, then become root through sudo for the tasks that need it, because SSHing directly as root is a security posture Ansible is built to avoid. The escalation is a separate, explicit step from the connection, and that separation is the whole idea worth understanding precisely.

Keeping the login and the privilege distinct is what lets a fleet run under least access without giving up the ability to install packages and write to /etc. This topic separates the connection user from the become user, walks the three knobs — become, become_user, become_method — covers per-play versus per-task escalation, the sudo-password flag, and why direct root SSH is the wrong default.

Connect as a User, Act as Root

Ansible's SSH connection and its privilege are two different things. ansible_user: deploy decides who logs in; become: yes decides who the task then runs as. You connect as a named, low-privilege account and escalate only for the work that needs root. This split is why you never put root in your SSH config — the login stays unprivileged and the escalation is an explicit, per-the-principle-of-least-access step.

Hold those two ideas apart and most of become follows. The connection answers "how do I get onto the box," the escalation answers "as whom do I run this task once I am there." They are configured separately, logged separately, and failing one is a different problem from failing the other.

become, become_user, become_method

Three settings control escalation. become: yes turns it on. become_user: sets the target identity — root by default, but you set it to postgres to run a task as the database owner. become_method: picks the mechanism, with sudo the default and su and others available for hosts that require them. Together they answer on, as whom, and by what means.

- name: Configure the database tier
  hosts: db
  become: yes                  # escalate to root for most tasks
  become_method: sudo
  tasks:
    - name: Install PostgreSQL 16
      ansible.builtin.apt:
        name: postgresql-16
        state: present

    - name: Create the larkspur database
      become_user: postgres     # this task runs as the DB owner, not root
      community.postgresql.postgresql_db:
        name: larkspur
        state: present

The play escalates to root for the package install, then one task overrides become_user to postgres for the database creation, which must run as the owner of the cluster. The connection user never changes — only who each task runs as once connected. That is the three knobs working together on one tier.

Per-Play vs Per-Task

Set become: yes on the play when most tasks need root, or on a single task when only it does. The common Larkspur pattern is exactly the one above: play-level root for installing packages and writing config, plus a per-task become_user: postgres for the database tasks that must run as the cluster owner. The play sets the default; the task sets the exception.

Choosing the level is about where the privilege belongs. If a play is mostly root work, declare it once at the play level and override the few tasks that differ. If only one task in an otherwise unprivileged play needs escalation, put become on that task alone. Both read clearly; scattering play-wide privilege across every task does not.

--ask-become-pass and the sudo Password

If the deploy account's sudo requires a password, the run needs --ask-become-pass — -K for short — to prompt for it once at the start. Without that flag on a password-required host, every escalated task fails at once, because sudo is waiting for a password that never comes. The alternative is sudoers config that grants the automation passwordless sudo for the specific commands it runs.

The failure mode is distinctive: not one task failing, but every escalated task failing together with a become-password error. When you see that pattern, the fix is almost always a missing -K or a sudoers entry that does not grant what the run needs. Knowing the shape of the failure turns a confusing wall of errors into a one-line fix.

Why You Don't SSH as Root

Direct root SSH is disabled on a well-run server — PermitRootLogin no — and for good reasons that become respects. Logging in as root removes the per-user audit trail, so you cannot tell who did what; it hands full control to anyone who obtains the key; and it skips the sudo log that records every escalation. Connecting as a named user and escalating keeps that log honest and the blast radius scoped to what sudo permits.

This is why become exists as a separate step rather than a convenience you can shortcut with ansible_user: root. The named-user-plus-sudo path is more secure, more auditable, and survives a server that hardens its SSH config. Reaching for root login to skip an escalation step trades all of that away for a few saved keystrokes.