Goss and InSpec Image Compliance Testing Prompt
Write automated server-spec tests with Goss (or InSpec) to validate golden images and provisioned hosts — packages, services, ports, files, users, and CIS controls — and wire them into the image build pipeline as a gate.
- Target user
- Engineers validating Packer images and configured hosts
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior infrastructure engineer who has gated golden-image pipelines on Goss and InSpec suites that catch misconfigurations before images ship. I will provide: - What I provision (OS, packages, services, agents, hardening baseline) - How images are built (Packer + Ansible/shell) and where they run - Compliance requirements (CIS level, internal baseline) - Where I want tests to run (in-build vs post-deploy smoke tests) Your job: 1. **Tool choice** — compare Goss (fast, lightweight, single binary, great for in-pipeline gates) vs InSpec (richer language, CIS profiles, compliance reporting). Recommend one or both for my case and say why. 2. **What to assert** — derive a test matrix from my provisioning: required packages + versions, services enabled and running, listening ports, file existence/permissions/ownership, users/groups, kernel params (`sysctl`), and absence of forbidden software. 3. **Goss suite** — author a `goss.yaml` covering the matrix, including `command` checks for things without native resources, and explain `goss add` for autogenerating from a known-good host. 4. **InSpec / CIS** — show an InSpec control block, how to consume an upstream CIS profile, waive controls with justification, and produce a compliance report (JSON/HTML). 5. **Pipeline integration** — run the suite inside the Packer build (provisioner) so a failing test fails the build, plus a post-deploy smoke run via `goss serve`/`render`. Show the Packer + CI snippets. 6. **Severity and waivers** — distinguish blocking controls from advisory, manage waivers with expiry, and avoid silent permanent suppressions. 7. **Drift use** — reuse the same suite on running hosts to detect configuration drift over time. 8. **Maintenance** — keep tests close to the provisioning code, version them, and regenerate the baseline when the spec legitimately changes. Output as: (a) the test matrix, (b) a complete `goss.yaml`, (c) an InSpec control + waiver example, (d) the Packer provisioner + CI gate snippet, (e) a plan to extend tests into runtime drift detection. Make failing tests block the build by default; treat advisory-only as the exception.