Ansible CIS/STIG Hardening Playbook Generator Prompt
Generate a CIS/STIG-style Linux hardening playbook with idempotent, reversible controls, check-mode support, and a per-control mapping you can audit.
- Target user
- Engineers building auditable Linux hardening automation against a benchmark
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior automation and security engineer who builds Linux hardening automation that auditors trust. You know that a hardening playbook that locks an admin out of their own host is a failure, so every control must be idempotent, reversible, gated, and traceable back to a benchmark item. I will give you a set of hardening controls or a benchmark section. Produce an Ansible role/playbook that applies them safely, with a control-to-task mapping I can audit. Steps: 1. **Per-control task design**: for each control, write an idempotent task using the proper module (`sysctl`, `lineinfile`/`template` for config, `pam`/`mount` options, `service`, `user`, `file` perms). Avoid `command`/`shell` unless there is no module, and guard those if used. 2. **Map each task to its benchmark ID**: tag every task with the control identifier (e.g. CIS x.y.z / STIG ID) so the role is auditable and selectable by tag. 3. **Make controls toggleable**: drive each control from a variable (`harden_ssh_disable_root: true`) with sane defaults, so risky items can be disabled per environment. 4. **Lockout-risk controls flagged**: explicitly mark controls that can lock out access or break services — SSH config, firewall/`nftables` rules, password/PAM policy, `umask`, account lockout — and recommend applying those last and verifying connectivity between steps. 5. **Check-mode and diff**: ensure controls report accurately under `--check --diff` and note any that won't. 6. **Back-out**: for each high-risk control, note how to revert (variable to false + rerun, or the original value to restore). Fill in: - Benchmark / controls to implement: [PASTE LIST OR SECTION] - Target OS and version: [e.g. RHEL 9 / Ubuntu 22.04] - Environment risk tier: [prod / staging / lab] - Controls that must NOT be applied here: [LIST OR "none"] Output format: the role tasks YAML with per-task benchmark-ID tags and toggle vars, a `defaults/main.yml` of the toggles, a table mapping control ID to task to lockout-risk, and a verification + back-out section. Order tasks so lockout-risk controls come last. Do not run this playbook. Treat SSH, firewall, PAM, and account-lockout controls as destructive: recommend a single test host, a second access path (console/out-of-band), and a --check --diff review before any apply, and a staged rollout afterward.
Why this prompt works
Hardening automation has a unique failure mode: success that locks you out. An SSH config tweak, a firewall rule, or a PAM policy applied fleet-wide can sever your own access before you notice. The prompt makes lockout-risk controls a first-class concern — they get flagged, ordered last, gated behind toggle variables, and paired with a back-out — so the role hardens hosts without trapping you outside them.
Auditability is the other half. By mapping every task to its benchmark ID and tagging it, the role becomes selectable, reviewable, and defensible to an auditor who wants to see control x.y.z implemented as a specific idempotent task rather than buried in a shell script. Toggle variables in defaults/main.yml let you tune the same role across prod, staging, and lab without forking it.
The guardrails reflect how careful operators actually roll out hardening: one test host with an out-of-band console open, a --check --diff review, then a staged rollout. The prompt refuses to run anything and insists every high-risk control be reversible, which keeps a powerful, blast-prone change firmly under human control.