feat(helmchart): add minAge field to delay artifact promotion

[Solvik]

Hello,

I've been thinking about this with the recent supply chain attacks and thought it would be an interesting feature to provide so we can add a layer of mitigation for flux users.

The idea is simple: add a spec.minAge field on HelmChart that requires a chart version to have been published for a minimum duration before it gets promoted as an artifact.
This way, if a malicious versionis pushed to a Helm repository, semver ranges won't immediately pick it up, giving time to detect and react before it hits any cluster.

Example

spec:
  chart: podinfo
  version: ">=6.0.0"
  sourceRef:
    kind: HelmRepository
    name: podinfo
  minAge: 168h

Implementation

• New sub-reconciler reconcileMinAge between reconcileSource and reconcileArtifact
• Publish timestamp sourced from ChartVersion.Created in the repo index, carried via a new CreatedAt field on chart.Build
• When blocked: sets ArtifactInStorage=False / ChartVersionTooNew, requeues for the exact remaining duration
• Ignored for GitRepository and Bucket sources (no timestamp available)

Of course, I'm happy to get feedback on the approach and open to any guidance on what would make this acceptable for the project

[stefanprodan]

Flux users should move away from HTTP/S repos and switch to OCIRepository, we have no plans on adding more features to the HelmRepository and HelmChart APIs.

The minAge feature could be added to flux-mirror which syncs Helm charts from HTTP/S repos to container registries. I suggest creating an issue for this feature in the flux-mirror repository.

[Solvik]

Thanks for the context, I wasn't aware HelmRepository type: oci was considered legacy. Would adding minAge to OCIRepository be in scope?

[matheuscscp]

Would adding minAge to OCIRepository be in scope?

Impossible, the OCI spec does not return timestamps when listing tags, like supported by the Helm index.

The solution for this problem is controlling the sync period yourself by running the flux-mirror CLI in your automation (e.g. in your CI). When syncing from HTTP/S Helm repos, minAge can be a feature in flux-mirror. When syncing from OCI repos, you will need to control the flux-mirror sync schedule yourself in order to delay ingesting new versions.

Please open an issue for minAge in flux-mirror 🙏

[matheuscscp]

Note: flux-mirror supports mirroring container images as well. It allows you to pace the ingestion of all the OCI artifacts involved in the delivery of your apps/infrastructure: OCI Helm charts, Flux OCI artifacts and container images. If you want a complete solution for pacing your upgrades, this is probably the best CNCF/Apache 2.0 tool being actively developed by CNCF maintainers at the moment.

[stefanprodan]

This minAge feature could trick users into thinking it's a security feature while it's not. If an attacker gains access to GitHub, it can modify the Helm index Created date, since the index file is stored in Git. Also with container images, the attacker can set the org.opencontainers.image.created to any timestamp at push time.

Why minAge works for npm, is due to the fact that npm is a SaaS that doesn't allow the publisher to manipulate the timestamps.

Given this, I don't think we should add this feature in Flux at all, it will trick users to upgrade while the charts/images timestamps are manipulated.

[stefanprodan]

We may have a chance to implement this in flux-mirror for signed OCI artifacts by looking at the signature timestamp in the public Rekor instance, since that timestamp can not be manipulated. This of course will not wok for Helm HTTP/S repos, it could only work for Helm OCI charts, Flux OCI artifacts, and container images signed with cosign keyless.

[matheuscscp]

Is there a limitation when configuring a private Rekor? Defining which Rekor the CLI should trust could be useful

[Solvik]

Thanks for taking the time to explain this during your week-end guys :)
I'll close this PR and keep an eye on flux-mirror features