Skip to content
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

Add sigstore support to verify signatures of plugins. #795

Open
marcofranssen opened this issue Aug 23, 2022 · 4 comments
Open

Add sigstore support to verify signatures of plugins. #795

marcofranssen opened this issue Aug 23, 2022 · 4 comments
Labels
kind/proposal lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.

Comments

@marcofranssen
Copy link

marcofranssen commented Aug 23, 2022

It would be great if krew integrates cosign.

This way upon plugin install krew can verify the signatures and transparancy logs of published plugins.

In the first releases we should make this optional for plugins to have signatures, but in the long run it would be good to enforce those signatures.

@ahmetb
Copy link
Member

ahmetb commented Aug 23, 2022

As things stand today, I have a suspicion that this would help only little bit to alleviate the concerns of the users, while complicating things a lot for the 200+ plugin developers.

We have not done a complete threat modeling, but the releases for plugins currently come from repositories and the downloaded artifacts are checksummed. Therefore, they are guarded for in-place replacement of the artifacts, however they are not guarded against a malicious maintainer or a breach of write access to the repository (sigstore doesn't help with these either).

This situation is worth monitoring as the tooling and the ecosystem around sigstore evolves.

tl;dr: It can maybe help someday, but I am not seeing exactly how it can contribute to our security in a notable way today.

/kind proposal
/priority awaiting-more-evidence
/lifecycle frozen

@k8s-ci-robot k8s-ci-robot added kind/proposal priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. labels Aug 23, 2022
@ahmetb ahmetb added the lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. label Aug 23, 2022
@marcofranssen
Copy link
Author

I'm also willing to contribute this feature. I also have experience in generating signatures, provenance and sboms for Go and Docker projects.

This is just an example, I build for a blog I wrote.

https://github.com/marcofranssen/slsa-workflow-examples/blob/main/.github/workflows/release-docker.yaml

E.g. Goreleaser has support for generating the signatures. Also the Github actions ecosystem has nice support, so I do think with a couple of lines documentation we can show how plugin developers with just a couple of lines of yaml (Github actions/goreleaser config) can add signatures to their plugins.

Let me know if a PR would be accepted introducing this feature (starting as optional ofcourse).

@ahmetb
Copy link
Member

ahmetb commented Aug 25, 2022

Hi Marco, my comment is not about the implementation, but the usefulness of it as things stand today. If there's not enough value add for users, having the code in repo is further maintenance burden on the maintainers.

@ahmetb
Copy link
Member

ahmetb commented Sep 29, 2022

related #745

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/proposal lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.
Projects
None yet
Development

No branches or pull requests

3 participants