HIP for expanding digest support#441
Conversation
Signed-off-by: Andrew Block <andy.block@gmail.com>
|
|
||
| ### Current Limitations | ||
|
|
||
| Helm currently supports referencing OCI-based charts by digest for install, template, and upgrade operations. While this capability provides the baseline level of functionality, there are gaps in its coverage for lifecycle management operators as well as it does not extend to dependency management. Chart dependencies in `Chart.yaml` can only be specified by version, and the `helm dependency` subcommand has no awareness of digests. Additionally, once a chart is installed, there is no record of the specific digest that was used, making it difficult to audit or reproduce deployments at the artifact level. |
There was a problem hiding this comment.
| Helm currently supports referencing OCI-based charts by digest for install, template, and upgrade operations. While this capability provides the baseline level of functionality, there are gaps in its coverage for lifecycle management operators as well as it does not extend to dependency management. Chart dependencies in `Chart.yaml` can only be specified by version, and the `helm dependency` subcommand has no awareness of digests. Additionally, once a chart is installed, there is no record of the specific digest that was used, making it difficult to audit or reproduce deployments at the artifact level. | |
| Helm currently supports referencing OCI-based charts by digest for install, template, and upgrade operations. While this capability provides the baseline level of functionality, there are gaps in its coverage for lifecycle management operators as well as it does not extend to dependency management. Chart dependencies in `Chart.yaml` can only be specified by version, which corresponds to a mutable tag. And the `helm dependency` subcommand has no awareness of digests when determining downstream versions. Additionally, once a chart is installed, there is no record of the specific digest that was used, making it difficult to audit or reproduce deployments at the artifact level. |
Perhaps include slightly more problem detail?
|
|
||
| ### --digest Parameter for Lifecycle Operations | ||
|
|
||
| Helm already includes a `--version` parameter for `install`, `upgrade`, and `template` operations. Include support for a `--digest` option to explicitly specify the OCI artifact to reference. |
There was a problem hiding this comment.
--version sha256:123abc... would also work. Ie. reuse the existing flag and avoid dealing with precedence rules (I'm a stickler for trying to minimize bloat in CLI parameters)
In theory 'version' is not the best term to refer to digest, but I do think in practice users will understand the concepts are interchangeable (they are a mechanism to resolve the artifact).
For confirming the version matches the digest, the syntax --version 1.2.3@sha256:abc123... works as well.
| digest: "sha256:abc123..." | ||
| ``` | ||
|
|
||
| When `digest` is specified, it takes precedence over `version` for resolution. If both are provided, Helm validates that the resolved version matches the specified digest and returns an error on mismatch. See [Behavior Summary](#behavior-summary) for additional details. |
There was a problem hiding this comment.
similar to the CLI flag -- could version: "sha256:abc123..." and version: "1.2.3@sha256:abc123..." work?
|
|
||
| ## Security Implications | ||
|
|
||
| This proposal strengthens Helm's security posture by enabling artifact-level pinning and traceability across the chart lifecycle. Recording digests in release metadata provides an auditable record of exactly which artifacts were deployed, supporting supply chain security practices. |
There was a problem hiding this comment.
| This proposal strengthens Helm's security posture by enabling artifact-level pinning and traceability across the chart lifecycle. Recording digests in release metadata provides an auditable record of exactly which artifacts were deployed, supporting supply chain security practices. | |
| This proposal strengthens Helm's security posture by enabling artifact-level pinning and traceability across the chart lifecycle. Recording digests in release metadata provides an auditable record of exactly which artifacts were deployed, supporting supply chain security practices. | |
| The proposal otherwise doesn't incur any security implications for Helm. The same version to digest resolution process happens today, this proposal just enables pinning of the (cryptographically secure) digests at dependency build time. |
For completeness, add a statement to say security posture is otherwise unchanged.
| - name: mychart | ||
| version: "1.2.3" | ||
| repository: "oci://registry.example.com/charts" | ||
| digest: "sha256:abc123..." |
There was a problem hiding this comment.
It probably makes sense for Chart.lock should have an explicit digest: field (in contrast to my above comments supporting a version: "1.2.3@sha256:abc123..." syntax).
| | Both `digest` and `version` | Resolve by digest, validate version matches digest | | ||
| | Neither | Existing behavior (resolve latest matching version) | | ||
|
|
||
| ## Backwards Compatibility |
There was a problem hiding this comment.
To note (awkwardly, as I have also proposed adding fields to Chart.yaml, is something I only discovered recently), HIP-0012 prohibits adding new fields to Chart.yaml.
I'm unclear on the rationale. The argument is perhaps that an old version of Helm won't understand any new field. But this is a "forwards compatibility" argument rather than backwards compatibility one.
There was a problem hiding this comment.
Perhaps also state that behavior for chart repositories unchanged?
2 participants
HIP describing the expansion of support for referencing and managing OCI based charts by digest