cert-manager / cert-manager

Automatically provision and manage TLS certificates in Kubernetes
https://cert-manager.io
Apache License 2.0
11.91k stars 2.05k forks source link

upload Helm charts to OCI registry and sign them with cosign #5566

Open developer-guy opened 1 year ago

developer-guy commented 1 year ago

Is your feature request related to a problem? Please describe.

With Helm v3.8.0, the OCI support became GA, which is a good chance to start publishing Helm charts to OCI-compliant registries. Because recently DockerHub announced that they are starting to support OCI Artifacts, so we can use DockerHub to store Helm charts on it. It also brings another opportunity to sign Helm charts stored as OCI Artifacts with [cosign]() to provide their integrity and use GitOps tooling such as Flux to reconcile them as they were stored as OCI artifacts, and Flux has capable of reconciling OCI Artifacts and verify the integrity before reconciling them.

So, here are following the task lists we need to complete:

- [ ] Upload Helm charts to OCI-compliant registries
- [ ] Sign them with cosign

Describe the solution you'd like Similar works have been done in the past, here are some examples:

Describe alternatives you've considered

Additional context /cc @stefanprodan @dentrax

Environment details (remove if not applicable):

/kind feature

developer-guy commented 1 year ago

I'm willing to work on both tasks with my colleagues @dentrax, would you mind assigning them to us ☝️

SgtCoDFish commented 1 year ago

Thanks for raising this! I definitely think having our charts also be available in an OCI compliant registry would be awesome.

There are a couple of things which might cause issues here. Have a read and let me know what you think!

Dockerhub

We don't use Dockerhub for distributing cert-manager container images - they're currently on quay.io. I'd think we'd be quite strongly against using a different OCI registry for our helm chart compared with our container images, since that would involve our users needing to manage two sets of credentials (dockerhub and quay.io) and in us having to manage two sets of credentials (one for pushing to dockerhub, one for pushing to quay.io).

This doesn't look like a huge problem since at a glance it appears that quay supports OCI helm charts, so we could simply use our existing quay infrastructure.

Complexity

I'm actually the one who implemented PGP helm chart signing and container image signing using cosign for cert-manager - and it wasn't particularly simple because of the slightly complicated nature of how cert-manager is built. We have an entire release tool - cmrel - to help with building and releasing cert-manager.

That means that adding this functionality is likely gonna require Golang code to be written in the cmrel codebase. We haven't really documented much how that works (although we have documented how to use it).

On the plus side, because we already have cosign container signing we already have a cosign key we can use for signing helm charts.

I'm not trying to put you off by talking about the complexity here - just trying to make it clear that it's not gonna be totally trivial to do this!

cmcga1125 commented 1 year ago

Hey! @developer-guy are you interested in doing this? if not I'm interested!, although I think it is probably a few tasks that could be broken up?

developer-guy commented 1 year ago

Yeah @cmcga1125 please go ahead I couldn't find time to take a look at this one but I'm happy to help you if you have any question or even better we could do it together, just limme know when you are up to work on it and we could have a call to start working on it 🫡

SgtCoDFish commented 1 year ago

signing the docker images (do we do this already?)

This bit is definitely already done!

Pushing the helm charts to a new location (takes a good bit of communication, as we saw with the old helm registry that died a few years ago)

I think this should be simple enough - our CI environment already has .dockerconfig which can push to quay.io, and I'd assume that could be used for pushing helm charts too.

signing the helm charts

We have some simple helpers for using cosign within our release process; it might not be too much work to extend them to add support for helm signing!

jetstack-bot commented 1 year ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. Send feedback to jetstack. /lifecycle stale

jetstack-bot commented 1 year ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close. Send feedback to jetstack. /lifecycle rotten /remove-lifecycle stale

developer-guy commented 1 year ago

I'm still interested in doing this, just couldn't find time to take a look at it

SgtCoDFish commented 1 year ago

/remove-lifecycle rotten

Fair enough! I'll remove the rotten tag :)

jetstack-bot commented 1 year ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. Send feedback to jetstack. /lifecycle stale

onedr0p commented 1 year ago

/remove-lifecycle stale

jetstack-bot commented 11 months ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. Send feedback to jetstack. /lifecycle stale

jetstack-bot commented 10 months ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close. Send feedback to jetstack. /lifecycle rotten /remove-lifecycle stale

onedr0p commented 10 months ago

/remove-lifecycle stale

onedr0p commented 10 months ago

/remove-lifecycle rotten

MaxRink commented 8 months ago

Given that popular registries like harbor have already dropped support for legacy charts this sis something that would be nice to see

gleb-boushev-effem commented 6 months ago

so this still not possible?

SgtCoDFish commented 6 months ago

If this is going to happen any time soon it's likely to be alongside moving our container images (see this proposal)

It's absolutely something we want to do but it requires someone to sit down and do it and we just haven't had the bandwidth recently.

I'm interested in this from @MaxRink :

Given that popular registries like harbor have already dropped support for legacy charts this sis something that would be nice to see

What does this mean in practice?

PrivatePuffin commented 6 months ago

What does this mean in practice?

This means that major implemenations are already dropping support.

We, as TrueCharts, for example now need to keep old-style helm-repo dependency support in our CI just because cert-manager is slow in implementing even a basic setup of OCI.

cert-manager-bot commented 3 months ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. /lifecycle stale

onedr0p commented 3 months ago

/remove-lifecycle stale

cert-manager-bot commented 3 weeks ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. /lifecycle stale

matletix commented 3 weeks ago

/remove-lifecycle stale