[Feature Request] Add a setter for `tag@digest` to help pin image hashes in places that do not natively take a digest as input

[alanrichman]

The Problem

Some Helm charts have values that allow you to specify the name, tag, and digest of an image separately, for example: https://github.com/kubernetes/ingress-nginx/blob/helm-chart-4.13.2/charts/ingress-nginx/values.yaml#L33

To automate pulling images for this chart from a private repository I could set my values like this:

image: mymirror.com/ingress-nginx/controller # {"$imagepolicy": "flux-system:ingress-nginx:name"}
tag: "v1.13.2" # {"$imagepolicy": "flux-system:ingress-nginx:tag"}
digest: sha256:1f7eaeb01933e719c8a9f4acd8181e555e582330c7d50f24484fb64d2ba9b2ef # {"$imagepolicy": "flux-system:ingress-nginx:digest"}
digestChroot: ""

Then in places like Deployments, Jobs, etc. that specify just an image I can use this:

image: mymirror.com/ingress-nginx/controller:v1.13.2@sha256:1f7eaeb01933e719c8a9f4acd8181e555e582330c7d50f24484fb64d2ba9b2ef # {"$imagepolicy": "flux-system:ingress-nginx"}

However there are many Helm charts whose values only allow you to specify the name and tag which makes it awkward to provide a digest using Flux image automation. Here are some examples of this behavior:

• External Secrets
• Harbor
• Flux2 Community Chart
• External DNS
• Trivy Operator

The best way I have found to get a digest in here is by way of post-build variable substitution.

# kustomization.yaml
postBuild:
  substitute:
    ingressNginxTag: v1.13.2 # {"$imagepolicy": "flux-system:ingress-nginx:tag"}
    ingressNginxDigest: sha256:1f7eaeb01933e719c8a9f4acd8181e555e582330c7d50f24484fb64d2ba9b2ef # {"$imagepolicy": "flux-system:ingress-nginx:digest"}
---
# helmrelease.yaml
image: mymirror.com/ingress-nginx/controller # {"$imagepolicy": "flux-system:ingress-nginx:name"}
tag: ${ingressNginxTag}@${ingressNginxDigest}

Possible Solution: Add a new tagAtDigest setter option

Use of this new setter would look like this:

image: mymirror.com/ingress-nginx/controller # {"$imagepolicy": "flux-system:ingress-nginx:name"}
tag: v1.13.2@sha256:1f7eaeb01933e719c8a9f4acd8181e555e582330c7d50f24484fb64d2ba9b2ef # {"$imagepolicy": "flux-system:ingress-nginx:tagAtDigest"}

I think that this could add a lot of value to the image automation controller since it would help organizations who want to pin digests for all sorts of reasons achieve this simply and without leaning on upstream product maintainers to make any changes to their charts.

[stefanprodan]

Another way of setting this directly in the HelmRelease is with:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: ingress-nginx
spec:
  postRenderers:
    - kustomize:        
        images:
          - name: ghcr.io/ingress-nginx/controller
            newName: mirror.com/ingress-nginx/controller # {"$imagepolicy": "flux-system:ingress-nginx:name"}
            newTag: v1.13.2 # {"$imagepolicy": "flux-system:ingress-nginx:tag"}
            digest: sha256:1f7eaeb01..... # {"$imagepolicy": "flux-system:ingress-nginx:digest"}

[alanrichman]

Learn something new every day, I did not know that Flux could patch the rendered result of a Helm release!

That being said I do not think that this is going to be the ideal solution for my use case. We have multiple environments each with several clusters in them, but we install our base tooling everywhere from a core set of manifests. We run continuously a promotion cycle to move new versions of these tools into our development environment and eventually up to our production environment. For example our base for External Secrets looks something like this.

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: external-secrets
  namespace: flux-system
spec:
  chart:
    spec:
      chart: external-secrets
      sourceRef:
        kind: HelmRepository
        name: mirror-repo
        namespace: flux-system
      interval: 1m
  values:
    image:
      repository: ${externalSecretsRepository}
      tag: ${externalSecretsTag}
    imagePullSecrets:
      - name: mirror-secret

We then have a "base Kustomization" that collects a handful of core tool configs into one, then that gets applied to all clusters. The version of the Helm chart is controlled externally by a dependency management tool so the latest in the Helm chart repo is always our target version. Then that same tool controls image promotion to our internal image mirror that we pull versions from using ImageRepository and ImagePolicy resources. It is a lot of hoops to jump through but it allows us to be very intentional and precise with our versioning which is a high priority for our customer and for the industry we are supporting.

Having to modify the HelmRelease manifest for each environment would not fall quite in line with the setup we have right now, but maybe our setup is less-than-ideal. We could add a post-renderer with a patch per-environment but that would add some extra cognitive complexity to the setup that may make it more difficult to trace. We are leaning pretty heavily into post-build variable substitution because we believe that it adds a really cool thing that Kustomize is missing natively.

I would also be happy to work up a PR that does this if you think that it might be a good fit for the tool.

Thanks!

[stefanprodan]

Having to modify the HelmRelease manifest for each environment would not fall quite in line with the setup we have right now

The postRenderers is like values, same HelmRelease patch needed. If you use Flux var sub, then you can do the replacements in postRenderers.