| hip | title | authors | created | type | status | ||
|---|---|---|---|---|---|---|---|
0018 |
Add Repository URL and tarball digest to a chart's release metadata |
|
2021-11-24 |
feature |
draft |
Currently there is no way of knowing the exact repository that a chart originated from for a given release. There are ways to guess by looking at the sources list in the chart metadata, but since this is provided via the Chart.yaml file, any forks of that repository will look identical. The only way to concretely know what the repository URL that was used at install/upgrade time is to populate a repository URL metadata field in the release during the install or upgrade. It should work for both traditional repositories behind an http web server, as well as an OCI compliant repository.
The second part of this proposal would include the tarball digest of a chart in the metadata. This aspect is less fleshed out in code yet, but would be a nice alternative for installing a local chart from a tarball when the repository URL would not be known. The reason this is useful is because it can be used when interacting with other third-party databases, such as artifact-hub.
The primary motivation is to have a helm-native way to track where a chart came from. Many of the motivations for this feature can be found in this issue: helm/helm#4256. To note a couple:
- An admin would like to know where a chart came from only by querying the cluster itself. Currently the only way to know where a chart came from is to keep track of it externally.
- Third-party tooling that provides recommendations on helm upgrades can query the cluster to get the repository URL to aid in this recommendation. See nova as an example.
- This metadata field could also populate output for the
helm lscommand in the future. That may be outside the scope of this particular feature.
In order to query for this in the cluster, the repository URL will need to be somewhere in the release object. The chart metadata portion of the release object already contains similar data and makes the most sense for this purpose.
Nothing would change from the user's perspective. With some modifications in the current code it's possible to add this metadata into the release object transparently.
The current idea for this implementation is to add a field in both the ChartDownloader and Metadata (in the pkg/chart/metadata.go file) structs to hold the repository URL. The Downloader is the logical place to derive the proper URL and then populate the Metadata field.
More specifically, the URL is included in the local repository index file for a locally named repository. For instance, running helm repo add [NAME] [URL] would add the repository to the index file with the [URL] passed as the real location to download charts. In the helm code, the downloader reads this file to find the URL which is what gets bubbled up to the release object.
When installing from either a locally packaged chart, or a locally unpackaged chart (or folder), the repoURL will be set to the value path to indicate a local source.
The chart metadata object would have new fields that looked like so:
"repoURL": "https://charts.fairwinds.com/stable"
"tarballDigest": "sha256:f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9"
And an OCI compliant repository would look like this (example is using ECR):
"repoURL": "oci://${ACCOUNT_NUMBER}.dkr.ecr.us-east-1.amazonaws.com/goldilocks"
"tarballDigest": "sha256:f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9"
There should be no impact to backwards compatibility.
A potential security issue would be private repository URLs becoming present in a cluster via this implementation. A potential fix for this would be to add a command line argument that would keep this field in the release object empty, but that would introduce something a user has to change in their workflow which may not be desirable. Another way would be to attempt a DNS match against a publicly available DNS server and if it's not found, then we do not populate the repository URL field.
Another option is to ignore this potential downside. Unclear if this would truly be an issue or not. Would love to have feedback on why it would be bad for an internal repository URL to be stored in the cluster. If it is decided not to store a private URL by default, we should add a flag to allow it.
A potential positive is that including the tarballDigest would mean that utilities could independently verify that a chart has not been altered. However, a caveat should be noted here: There is no guarantee that helm will rebuild exactly the same tarball if presented exactly the same input data because some input metadata (timestamps, ordering) may change. So we wouldn't necessarily want to assume that just because a tarball has a different SHA, it's data has changed and thus it is untrustworthy. The exact handling of this is left to implementation.
The feature can be documented by describing how we get the URL (taken from the description in the Specification section). The usage of this URL is up to a user or third-party tool developer, but the URL would be included in the release object as one more informational piece with no prescribed usage.
A PR has been created to show a possible implementation: helm/helm#10369
N/A. I don't know of any other ideas proposed for this feature.
N/A for now. As for github issues, this is still open and would be solved by this feature: helm/helm#4256
- Github issue that would be fixed by this feature: helm/helm#4256
- Github PR that proposes a solution for this: helm/helm#10369