feat(flipt, flipt-v2): support image.digest for tamper-resistant pinning#284
Merged
kodiakhq[bot] merged 2 commits intoMay 29, 2026
Merged
Conversation
Both charts currently render the image reference as
{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}
which means a `digest:` field under `image:` in values.yaml is silently
ignored at the template layer — and for flipt-v2 it's also rejected by
the JSON schema (`additionalProperties: false` on the image block).
That forces digest-pinning users to embed the digest into the tag:
tag: v2.8.0@sha256:921350bb…
which works (the OCI runtime honours the `@sha256:` suffix) but
diverges from the convention every other chart in the ecosystem uses
(separate `tag:` + `digest:` fields — bitnami, datadog, external-secrets,
cert-manager, etc).
This change adds an optional `image.digest` field to both charts. When
set, it is appended to the rendered image reference as `@<digest>`, so
the final string is `repo:tag@digest`. Behaviour with no digest is
unchanged.
Changes per chart:
- templates/deployment.yaml: append `@digest` when set
- templates/migration_job.yaml: same (job runs the same image)
- values.yaml: add `digest: ""` with a comment
- values.schema.json: add `digest` to image properties
- Chart.yaml: bump chart version (flipt 0.87.6 -> 0.88.0,
flipt-v2 2.9.2 -> 2.10.0)
- README.md: document the new value
Rendered output, verified via `helm template`:
- no digest set -> repo:tag (unchanged)
- digest only -> repo:chartAppVersion@digest
- tag + digest -> repo:tag@digest
`helm lint` passes for both charts.
erka
reviewed
May 29, 2026
erka
left a comment
Contributor
There was a problem hiding this comment.
Thank you @pawelfraczyk for doing this.
Contributor
|
It's probably possible to modify update action to inject digest when a new Flipt version is released. |
Per maintainer review (@erka), the helm chart's major version is kept in lockstep with the upstream app major version by the release pipeline. Drop the minor bumps back to patch bumps: - charts/flipt: 0.88.0 -> 0.87.7 - charts/flipt-v2: 2.10.0 -> 2.9.3
Contributor
Author
|
Versions adjusted per review — |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Both
fliptandflipt-v2render the container image as:so a
digest:field added underimage:in values is silently ignored. Forflipt-v2the chart's JSON schema (additionalProperties: falseon the image block) also rejects it outright.The workaround today is to embed the digest into the tag:
The OCI runtime honours the trailing
@sha256:so it functions correctly, but it diverges from the convention every other widely-used chart uses, wheretag:anddigest:are separate fields.What this PR does
Adds an optional
image.digestfield to both charts. When set, it is appended to the rendered image reference as@<digest>:renders as
docker.flipt.io/flipt/flipt:v2.9.0@sha256:921350bb….Behaviour with no digest set is unchanged.
Changes per chart
templates/deployment.yaml— append@digestto the image reference when set, via{{- with .Values.image.digest }}@{{ . }}{{- end }}.templates/migration_job.yaml— same (migration job runs the same image).values.yaml— adddigest: \"\"with explanatory comment.values.schema.json— adddigestto image properties (plus, in flipt-v2, this is needed to bypassadditionalProperties: false).Chart.yaml— bump version (flipt0.87.6 → 0.88.0,flipt-v22.9.2 → 2.10.0).README.md— document the new value.Verification
```bash
helm template t charts/flipt-v2
-> image: "docker.flipt.io/flipt/flipt:v2.9.0" (unchanged)
helm template t charts/flipt-v2 --set image.digest=sha256:921350bb…
-> image: "docker.flipt.io/flipt/flipt:v2.9.0@sha256:921350bb…"
helm template t charts/flipt-v2 --set image.tag=v2.8.0 --set image.digest=sha256:921350bb…
-> image: "docker.flipt.io/flipt/flipt:v2.8.0@sha256:921350bb…"
```
`helm lint` passes for both charts. CI `ct lint` + `ct install` should also pass — the change is additive and backward-compatible.
Why this matters
Pinning by digest is the canonical defence against tag republishing (the same
v2.9.0tag can be re-pushed to a different image at any time). With this PR, users can pin via the standard chart-author pattern instead of having to know about the embed-in-tag trick.