DevSecOps Practice Hub

Ansible Security

Secure Ansible content, credentials and execution across ad-hoc runs and automation platforms.

IntermediateAnsible SecurityInfrastructureIdentity

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Code Static analysis, secret detection and secure coding practices.
  • Deploy Policy enforcement, admission control and infrastructure security.
  • Operate Runtime security, secrets rotation and configuration reconciliation.

Overview

Ansible executes with privileged access across fleets. Security focuses on where credentials live, who can run which playbook against which inventory, and what is logged.

Why it matters

An automation controller with fleet-wide root is one of the highest-value targets in an estate.

How it works

  1. 01Content is linted and reviewed in git before it can be executed.
  2. 02Credentials are injected by the platform, never stored in playbooks.
  3. 03RBAC binds job templates to specific inventories and teams.
  4. 04Job output is retained centrally for audit.

Common tools

ansible-lintAnsible VaultHashiCorp VaultAnsibleAAPLinuxRed Hat

Implementation examples

bashLint content in CI
ansible-lint --profile production playbooks/
The production profile enforces naming, idempotence and risky-module rules.
yamlAvoid leaking secrets in output
- name: Configure application secret  ansible.builtin.template:    src: app.conf.j2    dest: /etc/app/app.conf    mode: "0600"  no_log: true
`no_log: true` keeps templated secret values out of job output and logs.

Best practices

  • Use `no_log` on tasks handling secrets.
  • Scope job templates to least-privilege inventories.
  • Pin collection versions.

Common mistakes

  • Running everything as a single shared machine credential.

Hands-on labs