feat(helm): add support for image digest

[francRang]

What this PR does / why we need it: Add support for image digest for all used images.

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged): Fixes #2221

[sozercan]

@francRang Thanks for the PR! Helm chart is auto-generated in Gatekeeper, and these changes will get clobbered when we do a new release. Please see contributing changes for modifying the Helm chart: https://open-policy-agent.github.io/gatekeeper/website/docs/help/#contributing-to-helm-chart

[francRang]

@sozercan Thank you for your input, I was able to generate the code as requested but only for 2 deployments: gatekeeper-controller-manager & gatekeeper-audit. How can I achieve the same for:

• Job/gatekeeper-update-namespace-label
• Job/gatekeeper-update-namespace-label-post-upgrade
• Job/gatekeeper-update-crds-hook
• Job/gatekeeper-delete-webhook-configs ?

I was looking at some commits that made changes to those files, and I don't understand how they generated the code. Are changes for these supposed to be manual?

[sozercan]

@francRang static components (like helm hooks) are available in https://github.com/open-policy-agent/gatekeeper/tree/master/cmd/build/helmify/static/templates

[francRang]

Made the requested changes to do things the right way. Let me know if I missed anything.

[ritazh]

@francRang Can you pls run make manifests so that all your changes are in the manifest_staging directory? e.g. readme updates are missing

[francRang]

Hi @ritazh just did, thanks for the feedback, had forgotten to do so last commit.

[francRang]

@sozercan Can you take a look at the changes please?

[sozercan]

@francRang why not set release or tag here?

for example: helm install ... --set image.release=v3.9.0@sha123... --set postInstall.labelNamespace.image.tag=v3.9.0@sha789 (in this case v3.9.0 is just for human readability purposes and will be ignored - it can be anything, the digest will take precedence)

[francRang]

@francRang why not set release or tag here?

for example: helm install ... --set image.release=v3.9.0@sha123... --set postInstall.labelNamespace.image.tag=v3.9.0@sha789 (in this case v3.9.0 is just for human readability purposes and will be ignored - it can be anything, the digest will take precedence)

I am not entirely sure what you mean. Are you suggesting that it would be better to have the tag/release field be the digest too instead of having the digest as a separate field?

Not sure if by "here" you meant to reference a line.

I can definitely do that, I would just need to detect a substring with the "@" character in it. Let me know if this is what you meant, sorry if I did not understand @sozercan .

[francRang]

Working on another chart, I saw an example of what you meant, I do see how that improves readability. Working on the requested changes.

[francRang]

@sozercan Applied requested changes. Let me know what you think.

[sozercan]

@francRang What I meant was, do we need this PR if we can specify a digest as part of release or tag value? Are there any advantages of adding a new digest value?

For example, today we can do: helm install ... --set image.release="v3.9.0@sha123" --set postInstall.labelNamespace.image.tag="v3.9.0@sha789" which will set the digest of gatekeeper to sha123 and gatekeeper-crds to sha789

[francRang]

@sozercan I was able to confirm that specifying the tag the way you mentioned works. Cosign supports the syntax (for image signature verification). Therefore, I agree it is redundant to have the digest as a separate field. Thanks for all the feedback!