LEARN. PRACTICE. GROW.1. Establish the automation destination
A fictional production team prepares two servers for a new file service. Before creating accounts, it needs to establish where each task will execute. The lab uses nodea and nodeb, two UBI 9 containers with separate SSH servers, plus a separate controller. Host keys are obtained through the controlled fixture setup channel and placed in a dedicated known_hosts file. A connection using a different recorded host key is rejected. This comparison demonstrates the configured identity check; automatically accepting any key observed over the network would have a different trust basis. In production, a server replacement may explain a new key, but the team should confirm that change through its authorized process before updating the record.
2. Separate the connection user from the execution user
Inventory connects as automation using a private key held only in the disposable controller. For the first id -un command, the play specifies become_user: root without enabling become. The result is automation. The next task enables become: true and returns root. Both results are observed on each node through SSH. The conclusion depends on effective configuration: an ansible_become variable at another level can alter the behavior expected from a directive. When a task fails on permissions, first inspect the connection user, escalation settings and applied sudo policy. Switching SSH directly to root can conceal the cause and expand access without fixing the approved execution design.
3. Validate a change before activating it
The play installs a demonstration rule allowing trainee to run /usr/bin/id as root. The copy module invokes visudo against its temporary candidate through validate before replacing the destination. A later run supplies a syntactically invalid candidate. The task fails on both nodes and the previous rule retains its hash. The full policy is then checked with visudo -c because validating a single fragment cannot detect every interaction with other included files. Two real calls are also made: the permitted command succeeds and a different command is denied. Syntax validity, file permissions and authorization behavior provide complementary checks. None independently establishes that the policy matches the organization’s access requirements.
4. Distinguish one-command policy from module execution
The restricted trainee rule is used to observe sudo decisions; that account is not the exercise’s automation identity. The automation user has a broad rule only inside disposable containers so the required modules can execute. Ansible may transfer code into temporary paths and execute it through an interpreter. Allowing only useradd or chmod does not establish that the user or file module will be authorized. A team must design automation access, protect credentials, constrain destinations and control who can launch changes. The lab’s broad rule is not a recommendation for real servers. When adapting an exercise, explicitly record differences among bootstrap access, execution identity and emergency access.
5. Deliver evidence with a precise scope
The report identifies versions, images, hosts, individual play results and post-execution checks. The controller uses ansible-core 2.20.10 and ansible.posix 2.2.2; targets use Python 3.9 on UBI 9. These are real SSH connections between separate userspaces, while the containers share the Docker virtual machine’s kernel. A complete RHEL boot, persistence after reboot, enforcing SELinux and AAP have not been validated. In the fictional handover, the team can accept evidence for the exercised account and SSH behavior while retaining separate criteria for those other components. An error-free recap supports the operations performed; it does not fill in platform checks that never occurred.
# Original lab: content/labs/rhce-remote-accounts
# Run the complete disposable lab: python3 run.py --output evidence-local.json
# Requires images built with Dockerfile.node and Dockerfile.controller.
# The runner provisions keys and inventory; this play belongs to that fixture.
# Inside the prepared controller: ansible-playbook -i /lab/inventory.ini /lab/identity.yml
- name: Prove connection identity and explicit escalation on each remote node
hosts: managed
gather_facts: false
become_user: root
tasks:
- name: Observe identity with become_user but without become
ansible.builtin.command: id -un
changed_when: false
register: connection_identity
- name: Observe identity after explicit become
ansible.builtin.command: id -un
become: true
changed_when: false
register: elevated_identity
- name: Observe target hostname
ansible.builtin.command: uname -n
changed_when: false
register: target_identity
- name: Assert connection and execution are different identities
ansible.builtin.assert:
that:
- connection_identity.stdout == 'automation'
- elevated_identity.stdout == 'root'
- target_identity.stdout == inventory_hostname
Without become, id returns automation; with become: true, it returns root. An invalid sudo candidate fails before replacing the working rule.
Common pitfalls
Disabling host-key checking to clear an error; treating become_user as activation; accepting sudo syntax alone; copying the broad lab rule into production.
Related topics: Accounts, groups and SSH revocation
Confirm the destination, observe both identities and test the authorized policy before accepting handover.
Reference: Privilege escalation: connection identity and become · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned