Closed mattmoor closed 8 months ago
If y'all are receptive to this, I'd be happy to send a PR with the above changes to the actions workflow, just let me know.
The published image are in a different repository. Moving this issue there.
I can help in the implementation
That would be great, I had this on my radar anyway. We use goreleaser in this project, I believe there's an integration with cosign already.
I'm assigning this to @mattmoor. If you need help, ping @cpanato :-)
Yep, the implementation should be more straightforward :)
@cpanato has forgotten more about goreleaser
than I will ever know. Carlos, if you want to take this on that'd be fantastic 🙏
PR: https://github.com/open-telemetry/opentelemetry-collector-releases/pull/207
also did others to updates some other things:
https://github.com/open-telemetry/opentelemetry-collector-releases/pull/205 for this one, if you are interested to use a distroless base image we can switch that
https://github.com/open-telemetry/opentelemetry-collector-releases/pull/206
I commented in the relevant PR already, but our final images are scratch images already. The alpine base is being used only for build stages.
I know that this issue is only about signing images. However, it would be good also to sign executables (especially for Windows and macOS). It looks like sigstore
does not handle it. See: https://github.com/sigstore/cosign/issues/2170 and https://github.com/sigstore/fulcio/issues/250.
Is your feature request related to a problem? Please describe.
I'd like to be able to verify that the images we are consuming from
otel/opentelemetry-collector-contrib
on DockerHub were produced by this repo's release automation.Describe the solution you'd like
I'd like to see the workflow used to publish your images use
sigstore/cosign
keyless signing to sign the published images, e.g. like the actions sample here.There are three main pieces to this:
You need
id-token: write
permissions to generate an identity token for the workflow:You need to install
cosign
Sign the resulting image:
This can then be used with assorted policy controllers to verify that the images published to DockerHub were produced by
.github/workflows/build-and-test.yml
even if the static DockerHub credentials have been compromised.Describe alternatives you've considered
You could also use
sigstore/cosign
to sign the images using a static key pair. However, this requires managing another secret (the signing key), and publishing your own verification key. Some projects (e.g. Google distroless) are signing things both ways, at least for now.Additional context
No response