RunBook AcademyAnsible

← All checklists in Ansible

QuarterlySecurity

Checklist: Automation security review

21 items ·15 critical ·5 warn ·1 info

Run this quarterly, and additionally after any change to the automation account, the branch protection rules, the pipeline, or the set of people who can trigger a production run.

It overlaps the secrets review deliberately but asks a different question. The secrets review asks what credentials exist and who can read them. This one asks what the automation is allowed to do, who can make it do something, and whether you would find out if somebody did.

What a failure means

Every critical item describes a way somebody could cause a change to the fleet without the estate noticing, or a way a compromise of one thing becomes a compromise of everything. Ansible is a lateral-movement tool with a friendly interface, and the difference between that being a benefit and a liability is this list.

Findings here are usually not urgent in the sense of an outage, and are usually expensive to fix, which is why they need a named owner and a date rather than a resolution before the review closes.

Access this needs

The host-side items go through the command module and read: sudo -l, sshd -T, cat authorized_keys, grep. They need become on the targets. The repository items are static reads. Nothing here writes.

Two items - branch protection and trigger access - are checked in the version control and CI systems, not from a shell, and two more - the network path and the detection - are attested by a person.

Where the evidence goes

Record the findings, the owner and the agreed date for each, in whatever register your organisation uses for security findings rather than in the repository. The items with no command - branch protection, trigger access, network path, detection, decommissioned trust - need the name of the person who confirmed them, because those are the five that an auditor will ask about and the five that a command cannot answer.

Sign-off

Reviewer: ________________ Date: ___________
Platform owner: ___________ Date: ___________
Security owner: ___________ Date: ___________

Critical15 items

Production and non-production use different automation accounts and different keys. One account across environments means a compromise of the staging path is a compromise of production, and it means no log can distinguish the two.
```
ansible-inventory -i inventories/production --list | jq -r '._meta.hostvars | to_entries[] | "\(.key) \(.value.ansible_user // "unset")"' | sort -u -k2
```
What the automation account may do under sudo is written down and matches the sudoers rules on the hosts. Prints the effective rules per host; `NOPASSWD: ALL` may be the right answer for a configuration management account, but it has to be a decision somebody made rather than the default nobody revisited.
```
ansible -i inventories/production web -m ansible.builtin.command -a 'sudo -l -U ansible' --one-line
```
The sudoers rule granting the automation its privilege is not maintained solely by the automation itself. A role that writes its own sudoers file means an attacker who can merge a change to that role can widen their own access, and the change looks like ordinary configuration management.
```
grep -rn 'sudoers' roles/ playbooks/
```
The automation account authenticates with a key and cannot authenticate with a password. Prints the effective sshd settings per host; `passwordauthentication yes` for an account with fleet-wide sudo is a brute-forceable path to the whole estate.
```
ansible -i inventories/production web -m ansible.builtin.command -a 'sshd -T' --one-line | grep -o 'passwordauthentication [a-z]*'
```
The automation account on each managed node trusts only the controller key. Every additional key in that file is another party with the automation account privileges, and the file is exactly where a persistent attacker would add one.
```
ansible -i inventories/production web -m ansible.builtin.command -a 'cat /home/ansible/.ssh/authorized_keys' --one-line
```
Host key checking is enabled. With it off, anything that can answer on port 22 from the controller point of view receives the automation credentials and a stream of privileged commands. No output is the pass condition.
```
ansible-config dump | awk '/^HOST_KEY_CHECKING/ && !/= True/ {print "FINDING: " $0}'
```
The controller reaches managed nodes over a management path that other hosts cannot use, and managed nodes cannot reach the controller back. A compromised web server that can SSH to the controller is a compromised fleet.
The branch production runs from is protected: no direct pushes, review required from somebody other than the author, and the protection cannot be lifted by the person merging. The repository is production configuration, and merge access is production access.
Who can start a production run is a short, enumerated list, and it is enforced by the pipeline rather than by convention. "Anyone who can SSH to the controller" is not a list, and it is usually longer than anybody expects.
The `ansible.cfg` in the repository does not redirect where code is loaded from. Prints any setting that changes a plugin, role, module or collection path; each one is a directory whose contents execute with controller privileges, so each one needs to be somewhere the review covers.
```
grep -nE '^(roles_path|library|collections_path|collections_paths|action_plugins|callback_plugins|connection_plugins|filter_plugins|lookup_plugins|inventory_plugins|strategy_plugins|test_plugins|vars_plugins)[[:space:]]*=' ansible.cfg
```
Every custom module, plugin and filter in the repository has been reviewed as code, not as configuration. Filter, lookup, callback and strategy plugins run on the controller, as the controller account, before any host is contacted - a malicious lookup plugin never needs a managed node at all.
```
ls -la library/ plugins/ filter_plugins/ action_plugins/ lookup_plugins/ callback_plugins/ 2>/dev/null
```
Collections and roles come from named namespaces at pinned versions, ideally through an internal mirror. An unpinned collection is a supply-chain dependency that updates itself, on a controller with fleet-wide root.
```
cat requirements.yml; ansible-config dump | grep -E '^GALAXY_SERVER'
```
You would notice a production run that nobody authorised. There is an alert, a log review, or a pipeline that is the only path - and somebody has tested that the detection fires. Automation that can change the estate silently is automation an attacker can use silently.
Keys and accounts for decommissioned hosts, retired controllers and departed engineers have been removed everywhere, not only from the systems anybody remembered. A retired controller whose key is still in authorized_keys across the fleet is a spare set of keys in an unlocked room.
Any automation that runs without a human - event-driven remediation, a scheduled convergence - has a host cap, a rate limit and a tested kill switch. Prints the schedule; an unbounded automatic remediation is a self-inflicted fleet-wide change waiting for its trigger to misfire.
```
systemctl list-timers --all --no-pager | grep -i ansible; crontab -l 2>/dev/null | grep -i ansible
```

Warning5 items

Where the environment allows it, the authorized_keys entry carries a `from=` restriction naming the controller. It converts a stolen key into a stolen key that only works from one address, which is the difference between an incident and an outage.
```
ansible -i inventories/production web -m ansible.builtin.command -a 'grep -c from= /home/ansible/.ssh/authorized_keys' --one-line
```
The controller key has been rotated within the agreed interval, and the rotation removed the old key from every managed node rather than adding the new one alongside it. Rotation that only adds is accumulation.
Nobody runs Ansible commands inside a repository they have not reviewed. Verified on 2.21.3: a non-world-writable directory containing `ansible.cfg` is loaded automatically, so a single `ansible-inventory` run inside a cloned repository can execute that repository plugins. Ansible only ignores the file when the directory is world-writable, and warns when it does.
```
ansible-config dump --only-changed | grep '^CONFIG_FILE'
```
Facts gathered from managed nodes are treated as attacker-controlled where a host could be compromised. A hostname or a package version rendered into a template, a shell command or a file path on the controller is remote input reaching privileged execution.
```
grep -rnE '\{\{[^}]*ansible_(hostname|fqdn|nodename|distribution_version|env)' playbooks/ roles/*/templates/
```
Where `become` is used, the method and the target user are both deliberate. `become_user` defaulting to root on a task that could run as the service account is privilege nobody asked for and nobody will notice.
```
grep -rn 'become_user\|become_method' playbooks/ roles/ ansible.cfg
```

Info1 item

The review, its findings and their owners are recorded with a date. A security review nobody can produce afterwards is indistinguishable from one that did not happen.