HIP for Identifying Images for Helm Chart

[runyontr]

This HIP identifies how a chart can describe the images needed by a chart for deployment for use in airgap deployments, SBOMs or general metadata.

[scottrigby]

Would this be better a top level images key in Chart.yaml, since this is a proposal for a new (optional) standard?

This would have the added benefit of allowing the items to be a map, instead of cast as a string.
Example:

Suggested change

	annotations:
	images:
	- name: podinfo
	image: ghcr.io/stefanprodan/podinfo:6.0.0
	- name: redis
	image: dockerhub.io/_/redis:6.0.8
	annotations:

[runyontr]

I think providing it as the native spec, rather than a supported annotation would provide a few benefits:

1. Better documentation/discovery
2. Easier integration as we add the properties to the Chart Struct.

[joshrwolf]

👍 for native/typed spec since one of the key desires is for downstream tools to consume and leverage this information, this would prevent each tool from implementing their own parser.

Also want to float the idea of using digests instead of tags for referencing images. On the one hand, digests allow for more repeatability and have a better immutability story considering this HIP is about pinpointing dependencies, but that might be undesirable considering the chart itself is versioned using a mutable tag. Thoughts?

[runyontr]

I would lean to support both and allow the chart owner to decide if they want to use a SHA or a tag for their application. Would you suggest breaking that into its own field so tools know how to concat the fields together?

images:
- name: podinfo
  image: ghcr.io/stefanprodan/podinfo
  tag: 6.0.0
- name: redis
  image: dockerhub.io/_/redis
  digest:  sha256:3235326357dfb65f1781dbc4df3b834546d8bf914e82cce58e6e6b676e23ce8f

[mattfarina]

images as a new top level element in the Chart.yaml file cannot happen until the next major version of Helm is introduced. This is due to the use of strict handling when the Chart.yaml file is loaded. This is done for security purposes and was a finding in a security audit. You can refer to the audits for more details on the issue.

An annotation is backwards compatible and lets us do it now.

[runyontr]

What's the right way to capture this top level image field as part of the 4.X release so that can be tracked?

[technosophos]

Two possibilities: Open a new HIP describing the change or mark this HIP as Helm 4, and not implement it in Helm 3. In theory, Helm 4's feature list is supposed to be built entirely from HIPs so that we have a documented forward path. This is after receiving backlash from people who felt that Helm 3 did not have an adequate set of planning documents.

[scottrigby]

Is this map structure for easy portability from existing artifacthub.io/images annotations? Asking because I don't yet understand the value of giving the image a name that's different from the image repo/name:tag path itself, which seems like it should be the primary key?

[runyontr]

I could see this switching to

images:
  redis:
    image: docker.io/redis:6.0.8

The non-URL use cases I'm seeing for adding additional fields would be to identify locations for signatures, sboms, etc. e.g.:

images:
  kafka:
    image: docker.io/bitnami/kafka:2.8.1-debian-10-r0
    bom: docker.io/bitnami/kafka:sha2562342342342343422342.bom
    signature: docker.io/bitnami/kafka:sha2562342342342343422342.sig
    public_key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqyIFy6N9IlhsJgXwBhJ+DXemtzFCo3aXYifBX+VJfe9Q3fTkdARn4cdNjTDFocjJSObRD8PxN8HEj1Vy2ziySA==

Both ArtifactHub and Openshift use the name field, but as you point out, I haven't seen any names that differ from the last part of the image URL, so could be duplicate information.

[joshrwolf]

How would the image reference need to change (if at all?) to accommodate non-default values for images. Or is the assumption that the images map (or whatever the ultimately agreed upon format is) is only valid with the chart authors default values.yaml?

[Boojapho]

Probably don't want to assume it is only valid with the defaults since that would eliminate the accuracy of a static analysis on a chart to extract the images. We need a way to identify images with all of the overlays in place. The community has asked about overriding Chart values in the past. Is there an alternative to providing overlays for Chart values if the use case is to identify image attributes without deployment?

[Boojapho]

Noticed in this HIP a request to override dependencies. Maybe a helm option to provide a Chart.yaml overlay is the best solution to cover both scenarios and appversion.

[mattfarina]

I would suggest focusing on images first instead of the other elements. The references to bom and signature point in a direction where security is in the loop. The references follow what's happening with sigstore. This should happen as part of a broader conversation (which I would like to have).

[scottrigby]

👍

[mattfarina]

Note that images listed in CRs based on CRDs can't easily be discovered because we don't know how to navigate that schema. Determining the images is a bit of a guessing game. I am glad that Artifact Hub, at least, is trying to figure out some of those things.

[joejulian]

Agreeing with the above, also any images referenced in binaries, like the velero operator, cannot be scraped so having a schema that the publisher can expose what images their chart uses seems like the best way.

If the publisher does expose a list, but those images can be overridden through values, do we need a way of merging the values into the published list?

[runyontr]

@joejulian are you suggesting putting a field for each image that specifies how an end user of the chart would override the image?

So for a chart that has

image:
  registry: docker.io/bitnami/kafka
  tag: 2.8.1-debian-10-r0
...

The chart metadata would specify how to change the image and tag via:

 annotations:
  images: |
    - name: kafka
      image: docker.io/bitnami/kafka:2.8.1-debian-10-r0
      registry: .image.registry 
      tag: .image.tag

[jhmadhav]

We do have a similar scenario but also to be able to pull images with digest, we could include digest as well.

image:
  registry: docker.io/bitnami/kafka
  digest: sha256:cba

...

 annotations:
  images: |
    - name: kafka
      image: docker.io/bitnami/kafka:2.8.1-debian-10-r0
      registry: .image.registry 
      digest: .image.digest

Even here I think we also need a way to figure out registry and digest/tag used by the chart beforehand without rendering the template

[technosophos]

I am good with merging this as-is.

I think it would be good (but beyond the scope of this present HIP) to continue work on:

• A separate (short) HIP describing a top-level image field for Helm 4
• Continued discussion about security/verifiability and for supporting alternate registries

[mattfarina]

This has the 2 required approvals. Merging.