Packer Golden Image Pipeline Prompt
Design a Packer build that produces hardened, reproducible golden machine images across clouds — provisioners, versioning, CVE scanning, and a bake-vs-boot decision framework.
- Target user
- Infrastructure engineers building immutable VM/AMI images
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior infrastructure engineer who has run golden-image pipelines that bake thousands of immutable images a month with full provenance.
I will provide:
- Target platforms (AWS AMI, Azure managed image, GCP image, vSphere, QEMU)
- Base OS and hardening requirements (CIS level, FIPS, org baseline)
- What goes in the image vs configured at boot
- CI system and where images are consumed (ASG launch templates, MIGs, node pools)
Your job:
1. **Bake vs boot** — give me a decision framework: what belongs IN the image (agents, hardening, base packages, runtime) vs what should be injected at boot (secrets, instance config, app version). Default to baking the slow/stable layer, booting the fast/changing layer.
2. **Packer template** — HCL2 `packer {}` block with required plugins pinned, `source` blocks per platform, and a shared `build` block. Show variables for region, base AMI lookup (via `data` source / source_ami_filter), and instance type.
3. **Provisioners** — order them: OS update → hardening (CIS via Ansible or shell) → install agents → app runtime → cleanup. Use the `ansible` or `shell` provisioner; explain why a `file` + `shell` combo beats inline heredocs for anything non-trivial.
4. **Reproducibility** — pin the base image by ID per region (not `latest`), pin package versions where it matters, and stamp the image with build metadata tags (git SHA, pipeline ID, build date, source AMI).
5. **Security** — run a CVE scan (Trivy/Grype) against the built image and FAIL the build on criticals; remove SSH host keys, cloud-init logs, bash history, and the provisioning user before finalizing.
6. **Versioning & promotion** — semantic image naming, a manifest post-processor that records the image ID, and how to promote dev → prod images by re-tagging rather than rebuilding.
7. **Cost & cleanup** — deregister old images + delete orphaned snapshots on a retention policy.
Output as: (a) full HCL2 template(s), (b) a hardening provisioner outline, (c) a CI pipeline with the Trivy gate, (d) an image-promotion + retention policy, (e) the top 3 reproducibility traps and fixes.
Bias toward: pinned everything, immutable + disposable images, and provenance you can audit.