opened
daurnimator
username_0
To ensure that a chart doesn't change out from under me, I'd like to include checksums in my generator (the same checksum you'd see in requirements.lock)
Support specifying checksum(s)
issue
created
mgoltzsche
username_1
Makes sense!
Would you like to create a PR?
comment
created
scjudd
username_2
Could most of [`helm.LoadChart`](https://github.com/username_1/helm-kustomize-plugin/blob/master/pkg/helm/helm.go#L235-L262) be replaced with a call to [`man.Build()`](https://github.com/username_1/helm-kustomize-plugin/blob/master/vendor/k8s.io/helm/pkg/downloader/manager.go#L62-L103)? From looking over this a bit today, it seems that `LoadChart` is doing a subset of the work of Helm's download manager's `Build` method.
comment
created
mgoltzsche
username_1
`helm.LoadChart` is also downloading dependencies while `man.Build()` isn't if I am not mistaken but you're right: this can probably be solved more elegantly or rather without copying code that helm provides anyway. I think I simply copied it from [ContainerSolutions/helm-convert](https://github.com/ContainerSolutions/helm-convert/blob/v0.5.1/pkg/helm/helm.go).

Also this repo has a [git_chart branch](https://github.com/username_1/helm-kustomize-plugin/tree/git_chart) which provides an additional but hacky feature: Referencing helm charts using go-getters and excluding particular resources like in [this example](https://github.com/username_1/kustomizations/blob/master/linkerd/base/linkerd-chart.yaml) where I fetched linkerd's helm chart from its git repo because they don't publish it but ship their own CLI that uses it. However I did not merge the feature into master because this is something you usually don't want to do.
comment
created
scjudd
username_2
Right, I didn't consider the initial download/unpack logic.

Well, I think I'll take a stab at this. :)
comment
created
mgoltzsche
username_1
@username_2 great!
To avoid potential conflicts and since I was using the go getter and resource filter features already I merged my very long-lived feature branch into master now.
comment
created
mgoltzsche
username_1
Solved by PR #5
comment
closed
mgoltzsche
username_1
issue
reopened
mgoltzsche
username_1
To ensure that a chart doesn't change out from under me, I'd like to include checksums in my generator (the same checksum you'd see in requirements.lock)
Support specifying checksum(s)
issue
created
mgoltzsche
username_1
I have to reopen this to clarify some requirements because I have to change some of the logic when upgrading to helm 3. The features for helm 2 done in PR #5 can be tested in release v0.9.2.

People (including me) were confused about the actual feature that should be implemented:
* Supporting `requirements.lock`: As I understand this is to lock to particular chart versions (in case the requirements.yaml specifies version ranges). In addition PR #5 introduced the field `lockFile` in the generator config so that you could point it to an existing  `requirements.lock` - here it was unclear how the user could easily update it and what its purpose is. Do you think this is needed and what would be your use case? Do you need it because you want to refer to a chart by version range within the generator config?
* Verifying an actual chart: this can be done using the generator config fields `verify` (bool) and `keyring` - should work but I didn't try it yet.

The changes introduced in PR #5 unfortunately don't work this way with the helm 3 code anymore (since e.g. `HashReq()` is inside a helm-internal package, see WIP PR #8). Therefore before I remove or reimplement the feature I need to ask if you really need to specify a lock file for a remote chart without specifying a local umbrella chart or rather if you need the `lockFile` field within the generator config? (if it is just about version ranges you could as well specify that single version and don't need another `requirements.lock` for it)
cc @username_0 @username_2 @james-callahan

_If you need the `lockFile` field I'd generate a temporary chart and place the chart reference from the generator config file into the `requirements.yaml` file of that temporary chart and nest values correspondingly to make helm deal with the `requirements.lock` and copy it back and forth to the project directory so that the user doesn't need other tools and knowledge in order to create that lock file initially - other opinions are welcome._
comment
created
daurnimator
username_0
@username_1 what I want to do is lock to a particular version of a chart, so that what I audit and test locally (e.g. cert-manager 1.0.1) is the exact same thing that gets deployed onto my cluster.

`verify` and `keyring` only check that it was signed by a given author; but I don't trust the author to not push out a malicious update in future overwriting their previous chart.

I was under the impression that the checksums in `requirements.lock` would protect against this issue, but perhaps not?
comment
created
mgoltzsche
username_1
That's not what the digest within the `requirements.lock` is for. As I understand it is to make the user rebuild her chart dependencies after she changed `requirements.yaml` (no idea why helm doesn't do it for us). You can see [here](https://github.com/helm/helm/blob/d481bc6cf32adf8a4684d58ae97002a9d7e70223/internal/resolver/resolver.go#L144) that the digest is just the hash of `requirements.yaml`.
I don't think helm supports the feature you're looking for.
However I think preventing redeployment would be very bad for desaster recovery.

Instead I recommend to use [kpt](https://github.com/GoogleContainerTools/kpt) to render a helm chart into a git repo using a kpt function/sink and commit and push the result (see [here](https://opensource.googleblog.com/2020/03/kpt-packaging-up-your-kubernetes.html)). Your CD pipeline (`kpt live apply .`) can always deploy the plain rendered manifests from the repo and you can reliably audit what gets deployed. Also you CD pipeline doesn't depend on rendering technology like helm or kustomize and availability of their repositories (kpt can also manage other (helm/kustomize/...) repositories within your repository).
There is also an official helm-template kpt function.

Soon I ll ship this project as kpt function/sink container image as well since it supports a few more features. As I understand, since they originate from kustomize, kpt functions will soon also be available within kustomize directly and eventually replace kustomize' plugins as they are today - the latter is just me guessing.
comment
created
mgoltzsche
username_1
I am closing this since `requirements.lock` is supported for local charts but does not guarantee that a chart does not change on the server.

@username_0 you can guarantee that manifests don't change after you have audited them using the [kpt functionality](https://github.com/username_1/khelm#kpt-function) for which I've also prepared an [example](https://github.com/username_1/khelm/tree/master/example/kpt/cert-manager) - though in practice you would also commit `example/kpt/cert-manager/static/generated-manifest.yaml` with the repository to be sure it doesn't change after you audited it and avoid dependencies within the CD pipeline (I just didn't do that to avoid polluting the repo for the sake of an example).
comment
closed
mgoltzsche
username_1
issue
created
mgoltzsche
username_1
fyi: there is now an [example](https://github.com/username_1/khelm/tree/master/example/kpt/linkerd) that shows how to pull in charts from other git repositories as kpt dependencies and render them with khelm.
comment