PS Product SecurityKnowledge Base

🤖 Ansible Security Baseline and Top 10 Misconfigurations

Intro: Automation magnifies intent. Secure Ansible design is mostly about source control, credential handling, approval flow, and limiting what automation can reach.

What this page includes

  • baseline security guidance
  • top 10 Ansible and AWX / Controller misconfigurations
  • comments on practical rollout

Baseline

  • keep playbooks, inventories, and roles in version control
  • require peer review before automation reaches production
  • separate playbook authors, credential admins, and platform admins where practical
  • store secrets in Vault or equivalent secret backends
  • do not expose AWX / Controller broadly to the internet
  • minimize superuser and sudo access
  • use signed or trusted collections and dependencies where possible
  • limit inventory and credential visibility to those who need it

Top 10 misconfigurations

  1. Production credentials visible to too many users
  2. AWX / Controller exposed directly to the public internet
  3. Shared admin or superuser accounts
  4. Playbooks that shell out excessively when safer modules exist
  5. Inventories with stale, privileged, or unscoped targets
  6. Secrets committed to repos or stored in plain variables
  7. Automation accounts with broad root or domain-admin reach
  8. No branch protection or approval flow on playbooks
  9. Third-party roles and collections used without review
  10. Logs or job outputs exposing secrets

Example checks

ansible-lint site.yml
ansible-playbook --syntax-check site.yml
grep -R "become: yes" .
grep -R "password:" .

Design comment

The most dangerous Ansible environments are the ones that feel efficient because they skip review, overtrust automation accounts, and treat inventories as harmless metadata.

2026 modernization notes

  • normalize older Ansible Tower references to AWX or Ansible Automation Platform Controller depending on whether you mean the community or supported product line;
  • prefer reviewed job definitions and execution environments over controller-local package sprawl;
  • treat ansible-container as historical context, not as a current recommendation;
  • validate playbooks and roles against newer ansible-core templating behavior before major upgrades.

Related page