# Safe Automation Practices — Ansible: Automate Servers with Playbooks

Source: https://www.geekswithgeeks.com/en/ansible/sec-safe-practices

> Review changes, protect the control node and restrict who can run what.

## 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.

```text
[ ] 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.

**Quiz:** Why run production playbooks through CI or a controller?

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

*Answer:* It records who ran what and enforces access control. Central execution gives auditability, consistent environments and permission control.