Ansible Fundamentals · Module 11 of 12

Privilege & safety

Use become deliberately, reduce blast radius, preview changes and keep credentials out of automation content.

Learning objectives

By the end of this module, you should be able to:

Explain become and why it is separate from SSH authentication.
Use check, diff and limit safely.
Apply least-privilege and secret-handling habits.

SSH identity and privilege escalation are different

Ansible can connect as one remote user and then request privilege escalation for tasks that require it. The become keyword expresses that escalation requirement. This separation allows organisations to keep direct root login disabled while using controlled sudo policy.

Reduce blast radius

Before a high-impact change, inspect targets, use --limit for a canary host or small group, and consider --check and --diff where supported. These controls do not replace backups, service-specific validation or change management, but they make mistakes less likely to affect an entire fleet.

Protect secrets and sensitive diffs

Do not place passwords or private keys in plaintext inventory. Use an approved secret mechanism, such as Ansible Vault or an external secrets system, and restrict access appropriately. Diff output can reveal secret configuration, so disable diff on sensitive tasks when necessary.

Worked examples

See the idea in practice.

Privilege escalation in a play

- name: Apply privileged configuration
  hosts: web
  become: true
  tasks:
    - name: Ensure chronyd is running
      ansible.builtin.service:
        name: chronyd
        enabled: true
        state: started

SSH authentication chooses how Ansible reaches the host.
become requests elevated execution for the play or task.

Preview narrowly

ansible-playbook -i inventory.ini site.yml --syntax-check
ansible-playbook -i inventory.ini site.yml --list-hosts
ansible-playbook -i inventory.ini site.yml --check --diff --limit web01

Validate syntax and targets first.
Check mode simulates supported task changes.
Diff can expose before/after file content, so use it carefully.

Suppress sensitive diff

- name: Deploy secret-bearing configuration
  ansible.builtin.template:
    src: secret.conf.j2
    dest: /etc/myapp/secret.conf
    mode: '0600'
  diff: false
  no_log: true

diff: false avoids before/after content display.
no_log: true suppresses task details that could reveal sensitive values; use it intentionally because it also reduces troubleshooting visibility.

Hands-on lab

Lab — Practice a low-risk rollout

Goal: Use target preview, check mode and a canary host before broadening a configuration change.

STEP 1

Preview target hosts

ansible web -i inventory.ini --list-hosts

STEP 2

Simulate one host

ansible-playbook -i inventory.ini web.yml --check --diff --limit web01

STEP 3

Apply to the canary

ansible-playbook -i inventory.ini web.yml --limit web01

STEP 4

Verify service

ansible web01 -i inventory.ini -b -m ansible.builtin.service_facts

STEP 5

Broaden only after verification

ansible-playbook -i inventory.ini web.yml

Verify

Only web01 changes during the canary execution.
The canary service reaches the expected state.
The broader run occurs only after verification.

Expected outcome

The learner can describe how each step reduces risk.

If it fails

If check mode produces incomplete results, determine whether the affected module supports meaningful check mode instead of assuming the simulation is authoritative.
If become fails, verify sudoers policy and credential strategy rather than enabling root SSH as a shortcut.

Real-world connection

Controlled rollout patterns such as canaries, serial batches and verification gates are central to safe infrastructure automation.

Avoid these traps

Common mistakes

Using root SSH because sudo policy is inconvenient.
Storing become passwords in plaintext files.
Running --diff on secret-bearing templates.
Treating check mode as a guarantee rather than a simulation.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1Is become the same thing as the SSH login user?

No. SSH establishes the connection; become requests privilege escalation for execution.

2Why use --limit on a risky first run?

It constrains the blast radius to a known subset or canary host.

3Why can --diff be dangerous?

It may display sensitive before-and-after configuration content.