-
Notifications
You must be signed in to change notification settings - Fork 506
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
Implement file signing step #2618
Comments
Until we decide on this, should development on #2600 be paused? |
@palnabarun Let's disucss it in the Jul 26 meeting (already added it to the agenda!) |
I have a work conflict with Jul 26 meeting. I will try to make it to the meeting, but for sure will catch up on the recording and notes. And, thanks for driving this conversation! |
NP, if you have any ideas or thoughts about this be sure to dump it here and I'll relay them to the rest of the team! |
Proposed KEP update incoming in kubernetes/enhancements#3451 |
Update: After the Jul 26 '22 RelEng meeting we chose to go via # 2: build file signing into krel via a new |
/assign |
@palnabarun are you planning to work on this? :) |
Yes, I am exploring this right now. I had a call with @puerco sometime back on some implementation details. I hope to start a WIP PR by next week for others to have a look at. |
@palnabarun do you need help on this topic from us? (cc @kubernetes/release-managers) |
I will take this issue, already discussed with @puerco |
add krel sign blobs and images commands
Background
As part of the Signing Release Artifacts KEP, we need to build file signing into our release pipeline. Up to now, we had considered building signing capabilities directly into krel. However, thinking a little bit more into the architecture of the pipeline it is possible we may end up not needing to work on it and instead could use standard cosign to sign the files.
Up to now, we had not considered that we need to sign our artifacts outside of
krel stage
. We do not only need to build a new step in the pipeline to sign files after they are built and staged, but we also need to move the current signing image signing logic out of krel (see #2611 for a more broad explanation of why).Our choice:
krel sign
or vanillacosign
This means we have two choices to implement the file signing step:
krel sign
subcommandcosign
release to sign the filesWe should only work on # 1 if there is a compelling reason to do it and, frankly, I'm failing to see one.
Architecture
In order to better understand how the signing step fits into the release process, let's take a look at how we sign images today:
The full proposal to sign files (and ultimately images too) would look like the following. This introduces a new signing step to handle the internal RelEng signatures. Initially would handle files but we should move the signing logic from krel to this new step too to restrict access to the signing account:
Should we cancel the development of our file signing codebase?
Short answer: No.
By no means this plan means we need to stop working on our file signing libraries. In the near future, kpromo should sign files just as it signs container images today. File signing in the release process should be seen as the Release Engineering stamp of origin of our artifacts and we should strive to get files stamped with a Kubernetes-wide signature.
The text was updated successfully, but these errors were encountered: