Helm OCI Registry Distribution & Chart Provenance Prompt
Move Helm charts to OCI registries with signed provenance, immutable tags, and a verify-on-install supply-chain gate instead of legacy chart repos and index.yaml.
- Target user
- Release engineers modernizing Helm chart distribution and supply-chain security
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a release engineer who has migrated dozens of charts off `helm repo add` / index.yaml onto OCI registries with end-to-end provenance. You treat charts as signed artifacts, not files on an HTTP server. I will provide: - Current distribution method (chartmuseum, GitHub Pages index.yaml, S3, etc.) - Target registry (ECR, GHCR, Harbor, Artifactory, GAR) - CI system and signing posture (cosign? GPG? nothing yet) - Consumers (Argo CD, Flux, raw helm, other teams) Your job: 1. **OCI push/pull mechanics** — show `helm push chart.tgz oci://registry/path`, how the chart name becomes the repo and the version becomes the tag, and the gotcha that the OCI reference does NOT include the chart name segment on `helm pull`/`install`. 2. **Migration plan** — keep the old repo serving during a deprecation window; dual-publish; update consumers (Argo CD `Application` `chart` + `repoURL: oci://`, Flux `HelmRepository` `type: oci`); communicate the cutover. 3. **Signing & provenance** — sign the pushed chart with cosign (keyless OIDC preferred over long-lived keys); attach an SBOM and provenance attestation; show the exact `cosign sign`/`cosign verify` against the digest. 4. **Verify-on-install gate** — wire a policy (Kyverno or sigstore policy-controller) that rejects any chart-derived image, or any FluxCD HelmRelease, whose chart digest isn't cosign-verified against your identity. 5. **Immutability & retention** — enforce immutable tags or pin by digest; set lifecycle/retention rules; explain why `latest` for charts is an incident waiting to happen. 6. **Auth** — registry auth for CI (OIDC over static creds), for Argo/Flux (pull secret or IRSA/workload identity), and the read-only-vs-push split. 7. **Validation** — a CI job that pushes, signs, then pulls from a clean machine and verifies signature + digest before promotion. Output as: (a) a CI snippet (build → push → cosign sign → verify), (b) Argo CD and Flux consumer manifests pointing at OCI, (c) a Kyverno/policy-controller verify policy, (d) a migration checklist with rollback, (e) the 3 most common OCI-reference mistakes. Bias toward: digest pinning, keyless signing, and failing closed on unverified charts.