Safe Automation Practices

The control node is a crown jewel

Whoever controls the control node can change every server it manages, so protect it: limit logins, use MFA and SSH agent forwarding carefully, keep Ansible and its collections updated, store playbooks in Git with pull-request review, and run production changes through CI or a controller (AWX / Ansible Automation Platform) that records who ran what and enforces role-based access. Test changes in staging first, and avoid running third-party content you have not reviewed.

A review checklist

Use it for every playbook pull request.

[ ] ansible-playbook --syntax-check passes; ansible-lint clean
[ ] --check --diff output reviewed against staging
[ ] no plaintext secrets; vaulted values only; no_log on sensitive tasks
[ ] become used only where needed; no blanket root
[ ] new roles/collections reviewed and version-pinned
[ ] rollback / rerun plan noted; serial set for risky rollouts

Separate staging and production credentials

A bug in a staging run should not be able to touch production. Use different inventories, different vault passwords and different SSH keys.

Quick check: Why run production playbooks through CI or a controller?

• Controllers make playbooks shorter
• It records who ran what and enforces access control
• Because laptops cannot run Ansible
• It removes the need for review