Skip to content

Publish Helm charts as OCI artifacts #15446

Description

@DrFaust92

What problem are you trying to solve?

Linkerd's Helm charts (linkerd-crds, linkerd-control-plane, and the extension charts) are only distributed through the classic index-based HTTP Helm repository at https://helm.linkerd.io/{stable,edge}. They are not published as OCI artifacts to any registry.

This is increasingly out of step with how charts are consumed today:

  • Helm has supported OCI registries natively and enabled-by-default since v3.8. OCI is now the recommended distribution mechanism, and helm push/helm pull/helm install oci://... are first-class.
  • GitOps tooling (Argo CD, Flux) and internal chart mirrors increasingly standardize on oci:// sources, so consumers currently have to self-mirror the Linkerd charts into their own OCI registry to fit that model.
  • OCI distribution comes with content-addressable digests and cosign/Sigstore signing support, which strengthens supply-chain guarantees over an unsigned index.yaml repo.

Several other CNCF projects have already added OCI publishing for exactly these reasons (e.g. kubernetes-sigs/external-dns#4630, kubernetes/autoscaler#7086).

How should the problem be solved?

Publish the Linkerd charts as OCI artifacts to a registry (e.g. cr.l5d.io alongside the existing images, or ghcr.io/linkerd) as part of the release pipeline, in addition to — not instead of — the existing HTTP repo so nothing breaks for current users.

Concretely:

  • On each stable/edge release, helm push linkerd-crds and linkerd-control-plane (and the extension charts) to the chosen OCI registry.
  • Optionally sign the pushed artifacts with cosign.
  • Document the oci:// install path in the "Installing Linkerd with Helm" docs.

Drawbacks / considerations:

  • Adds a publishing step and a registry namespace to maintain.
  • Two distribution channels to keep in sync (mitigated by driving both from the same release job).

Any alternatives you've considered?

  • Self-mirroring (the current workaround): consumers helm pull from helm.linkerd.io and helm push to their own OCI registry in CI. This works but pushes ongoing maintenance onto every user and defeats the point of an official artifact.
  • Staying HTTP-only: functional, but misses digest-pinning/signing and forces the mirror workaround for OCI-first GitOps setups.

How would users interact with this feature?

Install directly from the OCI registry with no helm repo add step:

helm install linkerd-crds oci://cr.l5d.io/linkerd/linkerd-crds \
  --version <version> -n linkerd --create-namespace

helm install linkerd-control-plane oci://cr.l5d.io/linkerd/linkerd-control-plane \
  --version <version> -n linkerd \
  --set-file identityTrustAnchorsPEM=ca.crt \
  --set-file identity.issuer.tls.crtPEM=issuer.crt \
  --set-file identity.issuer.tls.keyPEM=issuer.key

And reference it directly in Argo CD / Flux sources via oci://.

Would you like to work on this feature?

maybe

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions