HIP: images lock file #281
Conversation
Signed-off-by: Pablo Caraballo Llorente <[email protected]>
Adding some typo corrections, and punctuation marks. Also defining the image-lock Signed-off-by: mpermar <[email protected]> Signed-off-by: Pablo Caraballo Llorente <[email protected]>
Signed-off-by: Pablo Caraballo Llorente <[email protected]>
Signed-off-by: Javier J. Salmerón-García <[email protected]> Signed-off-by: Pablo Caraballo Llorente <[email protected]>
Signed-off-by: Pablo Caraballo Llorente <[email protected]>
Signed-off-by: Pablo Caraballo Llorente <[email protected]>
paleloser
force-pushed
the
images-lock-hip
branch
from
9a4f7b3
to
4a22413
Compare
Signed-off-by: Pablo Caraballo Llorente <[email protected]>
paleloser
force-pushed
the
images-lock-hip
branch
from
39b287c
to
db6e18b
Compare
| * An `images-lock.yaml` (or similarly named) would be backed up by a spec. plus it could contain other useful information such as the images' digests that can be used by supply chains to enforce additional good security practices. | ||
| * Helm could internally generate this file out of the `annotations` proposed in `HIP-0015`. | ||
| * Helm could apply an existing `images-lock.yaml` file to the _post-rendered_ manifests to enforce a BOM (just like others such as `npm` do with their `packages-lock.yml`). | ||
| * By parsing this file, Helm could help users to migrate Charts between registries, either by providing new commands or through new features in the existing commands. |
There was a problem hiding this comment.
This could also be developed as a plugin initially.
There was a problem hiding this comment.
Yes, this is a good point @joejulian . It might be worth actually to start this as a plugin.
There was a problem hiding this comment.
Took a while due to other priorities but we ended up following your advice @joejulian https://github.com/vmware-labs/distribution-tooling-for-helm
|
|
||
| It may be less relevant to the end users how is the `images-lock.yaml` packaged alongside the Helm Chart, whether if it is pushed to a different OCI blob, or how is it named in the registry. These points should be mentioned somewhere as well, but it's likely that with less emphasis. | ||
|
|
||
| In addition to the points made above, given the size of the improvement, promotion through conference talks, presentations or any other public conversation would be strongly suggested. |
There was a problem hiding this comment.
Maybe something in here about the linter and chart-testing
|
|
||
| ## Motivation | ||
|
|
||
| Container images are stored separately from Helm Charts. On one hand, this makes the Helm Chart really small in size. But on the other hand, this brings many challenges in terms of distribution and network access to images, which could be avoided if the application was self-contained. |
There was a problem hiding this comment.
From my experience, there are two differing ways helm charts are used:
-
The chart "floats" around the application. In that helm chart version X, can be used to install a range of application versions Y... e.g. https://artifacthub.io/packages/helm/kubegemsapp/nginx#nginx-parameters has the
image.tagproperty. Which effectively corresponds to the version of nginx being deployed (and which has little correspondence to the helm chart version there) -
The chart version is synonymous with the application version. ie. helm chart version X is used to deploy application version X. For which the chart must not allow parameterization of image tags. I don't know of an example in the wild, but we follow this pattern internally at my company for delivering software.
I think for this HIP to practically succeed, there needs to be a way to account for the first scenario. But don't get me wrong, also enhancing/formalizing a methodology for the second scenario would be fantastic. Very glad to see this HIP!
There was a problem hiding this comment.
This is great feedback @gjenkins8. I don't see much impediment in this proposal for 1. or 2. Basically what we are asking for Helm ecosystem is to have a way to generate a bill of materials at some agreed lifecycle command (e.g. helm dependency update). That command for example generates today a Chart.lock but in the future it could further decorate that lock or generate a different listing the container image dependencies.
Those container image annotations don't need to point to an specific version. e.g. a chart using nginx container could declare de dependency to 1.23.3, 1.23, 1, or not declare it at all and use latest. The lock file just states what was available at the given tag in dependency update time. As a Helm Chart is just a recipe, an user should always be able to use --set tag.image=1.12 and get an nginx deployment with nginx 1.12.
Now, lets say some new OCI/relocation/deployment/verification tooling exists built on top of this HIP and an user wants to use the latest nginx Helm Chart with nginx 1.12. That user, or automation, could simply change the annotation and pin that Helm Chart to that specific container image, or it could manually update the images lock (discouraged). Perhaps there are even more ways to do this.
Co-authored-by: Joe Julian <[email protected]> Signed-off-by: Pablo Caraballo Llorente <[email protected]>
|
For everyone falling into this PR. We have implemented a plugin that puts in practice the idea of a lock described in this PR. Hopefully this will serve as an adoption gauge as well. We are pretty excited about the possibilities that having this type of Check out the plugin at https://github.com/vmware-labs/distribution-tooling-for-helm |
In this HIP we're proposing a standard way of tracking a Helm Chart's container images through a new
images-lock.yamlfile, making easier to migrate whole Charts through different registries and generating a bill of materials, among other use cases.Find complete details on the improvement document.