Ansible become Method Selection Prompt
Choose and configure the right Ansible become method (sudo, doas, su, pbrun, machinectl) for a host class with correct flags and no credential leakage.
- Target user
- Engineers running Ansible across mixed hosts where sudo isn't the right or only privilege-escalation method
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Ansible engineer who knows `become` is not synonymous with `sudo`. You've configured `doas` on BSD-leaning hosts, `pbrun` where PowerBroker is mandated, `machinectl` for systemd containers, and `su` where sudo isn't available, and you know each has different flags, prompt handling, and failure modes. I will describe a host class and its privilege-escalation constraints. Recommend the right become method and the exact configuration. Steps: 1. **Match method to environment**: pick `become_method` from the constraints (which escalation tools exist, security policy, whether passwordless is allowed), and justify it over `sudo` if sudo isn't chosen. 2. **Set become_user and flags**: specify `become_user`, any `become_flags` the method needs, and where these live (group_vars vs play vs CLI) so they're scoped correctly. 3. **Password handling**: if the method prompts, recommend `--ask-become-pass` for interactive runs or a vaulted `ansible_become_password` for automation — never a plaintext password in inventory. 4. **Privilege scope**: confirm the escalation grants only what the tasks need; flag any task escalating to root that doesn't need to. 5. **Failure behavior**: describe how this method fails (wrong password, missing rule, prompt mismatch) and how to read the error. 6. **Verification**: give a one-task test (`ansible -b -m command -a 'id'`) to confirm escalation works as expected before running the real playbook. Fill in: - Host class and OS: [DESCRIBE] - Escalation tools available / mandated: [sudo / doas / pbrun / su / machinectl] - Passwordless allowed?: [yes/no] - Target privileged user: [root / service account] Output format: the recommended `become` config (method, user, flags) with where each setting lives, the password-handling approach, a privilege-scope note, and the verification command. Do not store become passwords in plaintext inventory. Recommend Ansible Vault or `--ask-become-pass`, verify with a single `id` command first, and escalate only to the user the tasks actually require.
Why this prompt works
Most teams conflate become with sudo and never think about it again, which works fine until they hit a host where sudo is not the answer — a BSD-leaning box running doas, an environment that mandates PowerBroker’s pbrun for audit reasons, or a systemd container where machinectl is the clean path in. Each method has its own flags, its own prompt behavior, and its own failure modes, and getting them wrong produces confusing escalation errors that look like authentication bugs. This prompt makes the method choice explicit and justified against the actual constraints rather than defaulting to sudo and hoping.
Password handling is where privilege escalation most often turns into a security incident. The temptation is to drop ansible_become_password straight into inventory or group_vars so automation runs unattended, but that plaintext value is a root-equivalent credential sitting in a repo. The prompt refuses that path, steering interactive runs to --ask-become-pass and automation to a vaulted variable, which keeps the convenience without the exposure.
The least-privilege step is the quiet win. It is easy to set become_user: root everywhere and move on, but every task that escalates to root widens both the blast radius and the audit scope. By asking which user each task actually needs and flagging unnecessary root escalation, the prompt keeps privilege scoped to the work. The single id verification before the real run closes the loop, confirming escalation behaves as expected on a representative host before the playbook touches anything important.