Sign container images

[sagikazarmark]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

Container images are not signed at the moment

Proposed Solution

Sign container images: https://github.blog/2021-12-06-safeguard-container-signing-capability-actions/

Alternatives Considered

No response

Additional Information

No response

[nabokihms]

It seems that we can safely add it, but does dockerhub support signatures? Maybe we can sign only images that are stored in ghcr.

[sagikazarmark]

Docker Hub free team is being sunset anyway, so we will probably have to abandon it anyway (or sign up for a Docker Open Source status or something)

[bnevis-i]

Apologies for the random comment, but it might be worthwhile to generate some signed SLSA provenance as well, to provide traceability to the commit ID, the workflow used to build the container, etc.

https://github.com/slsa-framework/slsa-github-generator/tree/main

[sagikazarmark]

Image signing is added to the pipeline, but the way its currently implemented makes it hard for providing instructions on verifying signatures.

Here is a discussion I started a while ago: sigstore/cosign#2936

tl;dr the identity signing the image is not the release workflow in our case, but the artifacts workflow (being called by the release workflow) which is unexpected. Furthermore, there seem to be no way to detect the actual identity from within the workflow (that we could provide in release notes for consumers to use as identity for verification).

(At least this was the case last time I checked)

[justaugustus]

@cpanato — this would be a great one for you to investigate, given your expertise here! :)

[cpanato]

Hello! I will start the work on this

[cpanato]

To solve that issue, we could maybe sign the image in the release pipeline instead of the reusable workflow, which would make it easier to verify the signatures. Wdyt @sagikazarmark?

[cpanato]

also i can implement the slsa generator if that is something we all want

[sagikazarmark]

Thanks for looking into this @cpanato

To solve that issue, we could maybe sign the image in the release pipeline instead of the reusable workflow, which would make it easier to verify the signatures.

I'd like to avoid that if possible.

The reason why we built our workflows this way is to maximize reuse between CI and release pipelines and make sure we test not just image building but the pipelines in CI as well. In my mind, that includes image signing as well.

As far as I understand, verification itself isn't the challenge. Giving consumers the information they need (signature identity) is. That's either a GHA or cosign issue IMO. (Or at least was a year ago, things may have improved since)

also i can implement the slsa generator if that is something we all want

That sounds great!

I actually looked at the available tooling to add SLSA to build pipelines (roughly 6 months ago), but they all required significant changes to our current pipelines.

I'm probably a little overprotective of how things are right now, but we've spent significant resources (ie. time and pain) to get where we are and my definition of "great tooling" includes easy to integrate into existing pipelines without the need for significant changes.

So if we can add SLSA without the need to rewrite our pipelines yet again, that would be great.

Thanks again for looking into this @cpanato !

[cpanato]

the slsa generator will be another job after this one https://github.com/dexidp/dex/blob/master/.github/workflows/artifacts.yaml#L31

if you want to make that for both release and main branch, if we just want that to the release we can add the job directly in the release.yaml

it is more what you would like. I can propose a PR.

[cpanato]

i think we can close this

[sagikazarmark]

Thanks 🙏