-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sigstore support #808
Comments
Is this option a user option, meaning derivatives would be the ones signing their artifacts and us just providing the method to do so, or this also includes signing our own artifacts? In that case, who is gonna create the private key and where its gonna be stored? It would need to be available in github in order to sign the packages which is a big security risk already ... :/ |
It does make sense also for us providing packages signed. Then it's user choice to verify or not the assets being downloaded
We can use github repository secrets to store the keys. Consider we did the same when we have added notary support too. |
ummm cosign doesnt seem to work on quay.io for now :/ sigstore/cosign#40 |
and it kind of not does 👍
|
we can use ttl.sh for testing (confirmed that it works) but until quay support is there, we wont be able to enable cosign. Should not take that long as version 3.6 of quay supports that, its just the hosted version needs to be updated. |
luet cosign plugin for luet created and published (as luet package) in here: https://github.com/rancher-sandbox/luet-cosign |
Github reports that the |
do we need everything to be on main? Its just force of habit, all my custom local tooling is kind of hardcoded with I cna change it afterwards, no problem |
I'd recommend to stick with github's new default |
@kkaempf done! |
In the case of building, I tested and the plugin signs everything correctly on push. So this is mainly done? The only problem is that quay is not supporting storing artifacts along so until that is in place, we cannot move forward with this. There is an en var used for "legacy" repos (
Next step is to try to store them in a different repo, althougth this seems more convoluted as we have to propagate that signature repo all around (on build, on install, on upgrade, etc...) but looks like we can do that :) |
Storing in a different repo works very nicely, so we can have our stuff in quay and the keys on dockerhub:
|
We gonna have a metting with Flavio to know more about the whole cosign thingies and the stuff around it (rektor, keyless, etc..) Then we gonna contact sec-team to know how to store private keys and such. So this is on hold for now. |
with #816 merged we now push signatures to raccos/releases-FLAVOR automatically on publish :D Test:
|
welp, as a side effect we also verify when luet {install,repo update} if we set the plugin:
Show nothing rigth? but the luet-cosign log show us that it was indeed verified:
|
With a patch for luet to print the plugin state on success the sign and verify is more clean to end users now. |
@mudler can you clarify what |
We have to provide a way, when building the derivative to rely on cosign in order to secure the supply chain. For example, in the context of : https://rancher-sandbox.github.io/cos-toolkit-docs/docs/creating-derivatives/creating_bootable_images/#example how do I use sigstore to verify what I'm installing is signed? |
isnt that already covered by the luet install using the plugin? like both cos-upgrade workflows and luet install workflow work in teh same way, so covering one, should cover the other? Of course, docs-wise should cover both but implementation-wise should be covered by adding the verify to luet install. |
goddammit the color of close tricked me |
Yup implementation wise we should be good. We just have to refine how to consume that process when building a derivative (where do I take cosign from? and the plugin?). Maybe we can create a package with all the tooling, so we can advertize to copy them from that image manually |
was thinking that maybe it should be part of the meta-minimal, both cosign and luet-cosing, so they are availabel out of the box? So then its just setting the correct env vars to have the verify as part of the derivative build |
or maybe create another meta, like |
with #823 merged we now by default verify on cos upgrade/deploy |
Docs are provided. rancher-sandbox/cos-toolkit-docs#54 |
Example of checking cos signatures in a derivative -> kairos-io/kairos#1 |
skip packages/repos is provided on https://github.com/rancher-sandbox/luet-cosign/releases/tag/v0.0.8 |
Is your feature request related to a problem? Please describe.
Currently we have the mtree plugin which allows to create manifests that can be used to match against installed packages. Although we want to provide a solution that can secure the full supply chain by also signing packages
Describe the solution you'd like
cosign support. This ideally should happen when:
luet install
when a user creates the derivativecos-upgrade
. When we give either a container image as input or a set of packagesNote that all the followings could be provided in form of a plugin/extension, as we do with mtree, and the above functionalities should be optional for the user.
follow up
The text was updated successfully, but these errors were encountered: