HIP for expanding digest support#441
Conversation
|
|
||
| ### 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.
There was a problem hiding this comment.
There is some weird validation on --version, since it is validated against the chart version, it would be easier to leave it as is and make users specify the digest on the uri like docker.io/library/busybox:1.36.1@sha256:685fb94d07cd4546452243d688cf7f0275811c75043bf724653556ae77607730 I think this may already work for v4.
| 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?
There was a problem hiding this comment.
The only alternative I can think of to avoid adding digest to Chart.yaml would be combine digest in the version like v1.0.0@sha256:e90098910a30b0b8cdeba9b99b0c79740a6b47ab591572a122849be5d985db6c which is the supported oci format, but that is a breaking type change too
sabre1041
force-pushed
the
hip-digest-support
branch
from
c5a0157 to
0490c01
Compare
|
@gjenkins8 @TerryHowe Updated the HIP based on comments/suggestions |
|
|
||
| ### Expanded --version flag for Lifecycle Operations | ||
|
|
||
| Helm already includes a `--version` parameter for `install`, `upgrade`, and `template` operations. Currently, this flag is limited to resolving to an OCI tag. Expand the representation within the `--version` flag to also include additional ways a specific chart chan be referenced. |
There was a problem hiding this comment.
| Helm already includes a `--version` parameter for `install`, `upgrade`, and `template` operations. Currently, this flag is limited to resolving to an OCI tag. Expand the representation within the `--version` flag to also include additional ways a specific chart chan be referenced. | |
| Helm already includes a `--version` parameter for `install`, `upgrade`, and `template` operations. Currently, this flag is limited to resolving to an OCI tag. Expand the representation within the `--version` flag to also include additional ways a specific chart can be referenced. |
|
|
||
| The following are valid options when specifying the `--version` flag: | ||
|
|
||
| * Chart version (Tag only only and represents the existing functionality) - `1.2.3` |
There was a problem hiding this comment.
| * Chart version (Tag only only and represents the existing functionality) - `1.2.3` | |
| * Chart version (Tag only and represents the existing functionality) - `1.2.3` |
|
|
||
| ### 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, which corresponds to a mutable tag. The `helm dependency` subcommand has no awareness of digests when determining dependant charts. 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, which corresponds to a mutable tag. The `helm dependency` subcommand has no awareness of digests when determining dependant charts. 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. The `helm dependency` subcommand has no awareness of digests when determining dependent charts. 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. |
|
|
||
| Documentation should be added to incorporate the enhanced ways of specifying chart versions including where they can be defined (within the CLI and the `Chart.yml` file) including how `version` and `digest` fields are surfaced in the `helm get` and `helm list` commands. | ||
|
|
||
| Guidance should also be provided to enable users to identify the digest of a chart. Chart creators or end users who manage Chart distribution can reference the digest property as it is provided as an output associated with the `helm push `command. |
There was a problem hiding this comment.
| Guidance should also be provided to enable users to identify the digest of a chart. Chart creators or end users who manage Chart distribution can reference the digest property as it is provided as an output associated with the `helm push `command. | |
| Guidance should also be provided to enable users to identify the digest of a chart. Chart creators or end users who manage Chart distribution can reference the digest property as it is provided as an output associated with the `helm push` command. |
|
|
||
| ### Expanded --version flag for Lifecycle Operations | ||
|
|
||
| Helm already includes a `--version` parameter for `install`, `upgrade`, and `template` operations. Currently, this flag is limited to resolving to an OCI tag. Expand the representation within the `--version` flag to also include additional ways a specific chart chan be referenced. |
There was a problem hiding this comment.
Expanding the --version flag doesn't add any functionality, it just adds different ways to do what can already be done. Expanding the flag would mean more validations. I think encouraging users to use the oci uri format and maybe even deprecating --version would be better.
Signed-off-by: Andrew Block <andy.block@gmail.com>
sabre1041
force-pushed
the
hip-digest-support
branch
from
0490c01 to
59a1839
Compare
|
@TerryHowe thanks again for the review. addressed the formatting concerns. Regarding your comment on the version flag, I updated the section heading to be more explicit that this HIP is targeting an expansion of the formats that can be used in the |
3 participants
HIP describing the expansion of support for referencing and managing OCI based charts by digest