Add minimum release age check to image policy

[hippogriffin]

With all the recent supply chain attacks in services like npm, new age gating features have been created to ensure only packages that are over a certain age can be pulled into applications.

This could be useful to have in flux image automation. Many images could be compromised by supply chain attacks and delaying the updates by a configurable time window could allow developers to manage this behaviour in flux in a similar way to npm.

This wouldn't be a panacea as image publishers ideally should have scanning in place and consumers could use tools like neuvector to scan images for vulnerabilities but it could be a helpful tool to have in the arsenal against such attacks.

I have a working controller that I've been testing but I'm opening this issue first as per the guidance.

What I've got so far is a configurable minAge and maxAge value that sits under filterTags that can be set in hours.

Here is an example policy:

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImagePolicy
metadata:
  name: tautulli
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: tautulli
  policy:
    semver:
      range: x.xx.x
  filterTags:
    minAge: 168h

Here is the output at the time of writing of kubectl get imagepolicy tautulli:

NAME       IMAGE                              TAG      READY   STATUS                                                                     AGE
tautulli   ghcr.io/home-operations/tautulli   2.17.1   True    Latest image tag for ghcr.io/home-operations/tautulli resolved to 2.17.1   4h44m

The absolute latest image at time of writing is 2.17.2 but this was released 5 days ago so it is filtered out.

[stefanprodan]

See:

• feat(helmchart): add minAge field to delay artifact promotion source-controller#2060
• Implement minAge for signature verification flux-mirror#23

[hippogriffin]

Nice. I didn't know about these features. I've tested this out and it works for me. I think this will work well for my workplace and we already have private registries.

I think it might not be the best solution for smaller businesses or homelabs where I could see people having to eventually pay for container registries to store the images, if they have large K8s clusters. GitHub is free at the moment but that could change and it adds an extra maintenance layer too.

If the cost of a cloud registry becomes an issue then people will have to host their own which means more hardware and bandwidth requirements. This seems inefficient if someone just wants to download the image from a trusted registry but vet the age of the images without that additional overhead.

As I say, I can make this work for me in my homelab but interested to hear opinions on the above and whether having the extra ability to manage this via the image reflector makes sense.

Thanks for all your work on this project btw. My homelab and my job wouldn't exist without it 🙏

[stefanprodan]

It's impossible to manage this from image automation, as i wrote on that closed PR:

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.

The only viable way to implement minAge is via public Rekor by looking at the signature timestamp, something that image automation does not do.

[matheuscscp]

Small businesses and homelabs can use e.g. GHCR.