release
release copied to clipboard
kubernetes
sign SBOMs through cosign tool right after generated it through bom tool
What would you like to be added:
We talked about a bit of generating/signing process of SBOMs on the sigstore Slack channel. In this talk @SantiagoTorres and @nadgowdas made a really valuable comment:
nadgowdas: In general, I think signing should be inherent to the SBOM generation process. If you have one task that generates SBOM, stores it in shared space, and other task signs it, then we are federating the trust across tasks. Maybe, the SBOM generation tool as a part of generation should automatically sign the SBOM
SantiagoTorres: Agreed, there's a slight time window in which it could have tampered. It shouldn't be too hard to tighten the distance between generation and signing with the available tooling though
👉 https://sigstore.slack.com/archives/C01D0PA9QKF/p1632149577045600
There is a tool called Syft created by the Anchore team. They also started to work for the direct signing of SBOMs right after generating them. Thanks to @luhring
👉 https://github.com/anchore/syft/issues/510
So, I'm proposing the same one for the bom CLI, we can use cosign as a library to sign SBOM documents right after generated them through the bom CLI because cosign has support for storing SBOMs on OCI Registry and also signing them.
cc: @Dentrax @dlorenc @erkanzileli
Great idea! I just added thoughts to anchore/syft#510 for what our first iteration could look like, and I'm curious what choices folks think would make sense here in the bom tool.
One part that I'll highlight: After beginning the implementation in Syft, I can tell that this kind of integration of signing/attesting will get much easier once it can leverage the work described in sigstore/cosign#844 for updating the lib API.
The initial draft of the sining KEP is proposed in https://github.com/kubernetes/enhancements/pull/3061
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
1. cosign as a library
Using cosign as a library would bring a bunch of transitive dependencies due to large go.mod file. ^1 It might eventually result in larger size of binaries. @spiffcs implemented cosign in Syft ^2 and binary size increased ~40MB. The concern here is:
Large dependency trees lead to larger built binaries (see above), larger attack surfaces, longer and more fragile builds, and (most interesting to me personally as a maintainer!) more toil for maintainers to update dependencies and sift through security alerts for those vulnerabilities. - @imjasonh
2. cosign as a binary
On the other hand, the concern here is, calling cosign binary right after generation of SBOM, leads to a slight time window in which it could have tampered. I'm agreeing with @nadgowdas, as he said: "signing should be inherent to the SBOM generation process."
I'm confused on which path should we follow here. Some help needed here to proceed on this issue so let me cc'ing @puerco. We (@developer-guy) want to get into it!
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
Signing Release Artifacts KEP is in Beta status now. Status for beta is "Standard Kubernetes release artifacts (binaries, container images, etc.) are signed." this means that we are signing SBOM now.
Here is a discussion https://github.com/kubernetes/release/issues/2618 on vanilla cosign or krel sign by @puerco about it. Building signing into krel was the final decision. It was included into #2742.
Maybe @cpanato, @puerco or @saschagrunert can confirm this is done now, from what I can interpret. If I understand it it correctly it done only not by using cosign directly but by implementing it close to generation inside krel.
Hey folks,
Any update on this issue, we (in Cluster API + possibly it's providers) also interested in this and would be great to see it happen.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale