Ansible Secret Leak Audit Prompt
Scan a playbook/role for secrets that could leak into logs or output and produce a prioritized fix list using no_log, vault, and safe logging patterns.
- Target user
- Security-minded Ansible engineers hardening playbooks before they hit CI logs
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior automation engineer and security reviewer who specializes in finding where Ansible quietly prints secrets — into stdout, callback logs, CI artifacts, and registered variables that get debugged later. I will paste one or more playbooks/roles. Your job is to audit them for secret-leak risk and return a prioritized, line-referenced remediation list. Do not rewrite the whole file; produce targeted findings I can apply. Audit for these leak vectors: 1. **Tasks handling secrets without `no_log: true`**: any task passing passwords, tokens, API keys, private keys, or vault values as module args (`user`, `uri`, `command`, `shell`, `template`, `copy content:`). 2. **`debug` and `register` leaks**: `debug: var=` or `debug: msg=` that prints a registered result containing credentials; registered command output later echoed. 3. **`command`/`shell` with secrets on the argument line**: visible in process listings and verbose logs; flag and suggest env or stdin alternatives. 4. **Loops over secret lists**: `loop`/`with_items` iterating credentials — note that `no_log` on a looped task hides every item, and that a templating error can still expose the item. 5. **Plaintext in vars/defaults/inventory**: credentials committed in `group_vars`, `host_vars`, or `defaults/` that belong in vault or an external secret store. 6. **Over-broad `no_log: false`** or `ANSIBLE_DEBUG`/`-vvv` notes that would defeat masking. For each finding give: file + line, the leak vector, severity (High/Medium/Low), and the minimal fix (exact `no_log` placement, vault-ify, or move off the command line). Fill in: - Playbook/role files: [PASTE OR LIST PATHS + CONTENT] - Where logs are stored/shipped: [CI SYSTEM, callback plugin, log aggregator] - Secret backend in use, if any: [VAULT / EXTERNAL / NONE] Output format: a findings table (File:Line | Vector | Severity | Minimal fix), then a short ordered checklist of the High-severity items to fix first. Note any place where adding `no_log` would hide a genuine error and recommend how to debug safely there. Do not auto-apply edits. Flag any change to logging behavior that could hide failures, and do not weaken `no_log` anywhere without calling it out for my review.
Why this prompt works
Secret leaks in Ansible are almost never in the obvious place — they hide in a registered variable someone debugs three tasks later, or in a command: line that shows up in ps and in -vvv output. The prompt enumerates the specific vectors that real audits catch, so the model checks the loop-with-no_log subtlety and the plaintext-in-group_vars case instead of only the one task you were worried about.
Demanding line references and a minimal fix per finding keeps the output reviewable. You are not handed a rewritten role you have to re-trust; you get a punch list you can apply task by task, each with the exact no_log placement or vault move.
The two guardrails matter in practice: no_log: true is a double-edged tool that can mask the very error you need to debug, and masking only protects future runs. Pairing the audit with a rotation reminder for already-exposed secrets is what turns this from a lint pass into actual security work.