What does signing and digest-pinning a Helm chart published as an OCI artifact prove about the images it deploys?
answer
- a chart is a pointer document
- the wrapper is not the contents
- tags resolve, digests pin
- subcharts and overrides are outside the signature
- verify images where they are pulled
basics
~20 sNothing about the images. Signing and pinning prove only that the chart is the exact bytes a known publisher produced; its values still point at container images by mutable tag, resolved and verified separately, or not at all.
solid answer
~40 sA chart is a pointer document, so verifying it verifies the pointer, not the target. A signature tells you who published this chart and a digest tells you the bytes did not change, but the values inside still name images — and if they name a tag rather than a digest, the same verified chart deploys different bytes tomorrow. Three gaps follow: mutable image references, subcharts pulled as separate artifacts that your chart verification never covered, and install-time value overrides that mean the configuration you verified is not the one applied. The fix is to pin every image reference to a digest inside the chart, verify those images independently at the point they are pulled and run, and treat the rendered output rather than the package as the thing you actually attest.
code
yaml · 6 lines# values.yaml, inside a chart that is signed and pinned by digest
image:
repository: registry.internal/payments-api
tag: "1.14" # mutable: resolves to whatever 1.14 points at today
# digest: sha256:... # content-addressed alternative
...go deeper
Be ready to state that a chart mostly contains references, and that a signature over it covers those bytes only. Knowing that a tag can be repointed while a digest cannot is the recall being tested here.
Explain the mechanics: which reference is content-addressed and which is mutable, when each is resolved, and why subcharts and overridden values sit outside the signed package entirely. Name the two independent verifications and when each fires.
Show how you would close it across many clusters: digest-pinning images inside the chart with automated bumps, verifying images where they are pulled, and attesting rendered output so the verified document is the applied one. Say what breaks operationally.
Own the trade: full digest pinning makes every image update a chart release, which teams will route around unless the automation is good. Decide what the platform guarantees, what consumers must verify themselves, and how you know sixty clusters are actually enforcing it.
## Verifying a wrapper is not verifying its contents A packaging artifact — a chart, an installer bundle, a manifest set — is mostly a set of references plus the parameters used to fill them in. When you sign it and pin it by digest, you get two genuine but narrow guarantees: - **Integrity:** these are the exact bytes that were signed. A digest reference is content-addressed, so a fetch either returns those bytes or fails. - **Provenance:** a known key vouched for those bytes, so you can attribute the artifact to a publisher. What you do **not** get is any claim about what the referenced things are. The chart says *deploy the image at this coordinate*; the registry decides what that coordinate resolves to at pull time. ## Where the gap opens **1. Mutable image references.** A values file that names a tag resolves through a mutable pointer. The chart's digest is fixed forever; the tag it contains can be repointed at any time by anyone with push rights to that image repository. Signing the chart hardens the wrong half of the pair. Pinning the image by digest inside the chart closes it, at the cost of a chart change for every image update — which is exactly the trade a platform team has to accept if the chart is to mean anything. **2. Dependencies.** A chart may declare subcharts that are fetched as separate artifacts. Verifying the parent says nothing about them unless the dependencies are themselves pinned by digest and vendored into the package you signed. Otherwise your one verified artifact is a front door with several unwatched side doors. **3. Install-time overrides.** Values can be overridden when the chart is installed, so the deployed configuration can differ from the one inside the signed package — different image, different privileges, different mounted secrets. If your control story is *we verify the chart*, an override silently invalidates it. ## The threat this actually models Picture a platform team distributing one chart to sixty clusters. The interesting adversary is not an anonymous attacker; it is a compromised publisher or vendor position — someone who can push to a repository that sixty clusters already trust. Chart signing gives you attribution and blocks tampering in transit and at rest. It does not stop that same position from changing what a tag points at, and the asset at stake is whole-cluster integrity: whatever image lands runs with the service accounts, host mounts and network position the chart grants it. ## What to do instead - **Pin image references to digests in the chart.** The reference becomes content-addressed and the chart's guarantee finally extends to what it deploys. Automate the digest bump so pinning does not turn into staleness. - **Verify images where they are pulled and run.** Chart verification happens at install; image verification has to happen at the point the platform actually fetches and starts the image. Those are two independent checks and the second one is the one that protects the workload. - **Attest the rendered output, not just the package.** Render the chart with the values you intend to use, pin the result, and make that the artifact you sign and apply. Then what was verified and what was applied are the same document, and overrides stop being an invisible bypass. - **Constrain overrides.** If a small set of values is legitimately environment-specific, enumerate them; everything else should be fixed in the signed artifact. ## Say the direction of each claim correctly The reason this question separates candidates is that all three trust primitives are in play at once and they answer different questions. *Who vouches for this* is the signature. *Which bytes* is the digest. *What is inside* is an inventory. **None of them answers what this artifact will cause to run** — that comes from the references being content-addressed and independently verified. A chart that is signed, pinned and completely trustworthy can still deploy an image nobody has ever checked.
- If chart verification does not cover the images, where does image verification have to happen?At the point the platform actually fetches and starts the image, as a check independent of the chart. That check looks at the image's own digest and the signature over it, and it has to fail closed. Verifying at install time only tells you the package was authentic; the workload starts later, from a reference that was resolved later.
- Operators install the chart with overridden values. What does that do to your verification story?It breaks the link between what you verified and what runs, because the applied configuration is no longer the signed one. Either enumerate a small allowed set of environment-specific values and fix everything else in the package, or shift the attestation to the rendered manifests so the artifact you sign is literally the document being applied.
- Does the same gap apply to subcharts your chart depends on?Yes, and it is easy to miss. A dependency fetched as a separate artifact at package or install time was never inside the bytes you signed. Pin dependencies by digest and vendor them into the package you publish, otherwise your single verified artifact quietly pulls in unverified ones.
saying these in an interview costs you the question
- Says a signed chart means the deployment is verified end to end
- Assumes verifying a wrapper covers everything it references
- Thinks pinning the chart digest also pins the images
- Confuses who published a chart with what the chart runs
- Forgets install-time value overrides change what is applied