-
Notifications
You must be signed in to change notification settings - Fork 71
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 RFC for cosign integration #195
base: main
Are you sure you want to change the base?
Conversation
Maintainers, As you review this RFC please queue up issues to be created using the following commands:
Issues(none) |
Cosign maintainer here! We'd love any feedback on the SBOM use case. This is really just a first draft based on how we guessed people might use it. If there's anything you don't like or we could change to make things easier we can do that! I'm excited to see it used here at all. |
# Motivation | ||
[motivation]: #motivation | ||
|
||
Supply chain security has been on top of everyone's minds in 2021. It is important to ensure the integrity and origin of software artifacts in order to have a secure supply chain. Sigstore's cosign has quikcly risen to become the defacto container signing solution. This RFC proposes that we natively add cosign support to the lifecycle to facilitate easy signed container artifacts as part of the build process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Supply chain security has been on top of everyone's minds in 2021. It is important to ensure the integrity and origin of software artifacts in order to have a secure supply chain. Sigstore's cosign has quikcly risen to become the defacto container signing solution. This RFC proposes that we natively add cosign support to the lifecycle to facilitate easy signed container artifacts as part of the build process. | |
Supply chain security has been on top of everyone's minds in 2021. It is important to ensure the integrity and origin of software artifacts in order to have a secure supply chain. Sigstore's cosign has quickly risen to become the defacto container signing solution. This RFC proposes that we natively add cosign support to the lifecycle to facilitate easy signed container artifacts as part of the build process. |
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
Increased complexity in lifecycle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recall we discussed this in sub sync, but is it possible to add the advantage of having the lifecycle do the signing vs leaving it up to the platform?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does it increase the complexity here ? Could someone add more details ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is no longer going to be part of the lifecycle and should be updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this moves outside lifecycle
to being a platform responsibility, does the binary belong within the lifecycle distribution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not... but in this case pack create builder
should be expanded to include optional platform-provided binaries within the builder at the desired location.
Signed-off-by: Sambhav Kothari <skothari44@bloomberg.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I recall correctly, this RFC falls under the same idea as other external operations such as preparer
. Those of which I believe we would develop PoCs independently and try to incorporate back into the project via these guidelines. If so, should this be a draft or closed?
# Motivation | ||
[motivation]: #motivation | ||
|
||
Supply chain security has been on top of everyone's minds in 2021. It is important to ensure the integrity and origin of software artifacts in order to have a secure supply chain. Sigstore's cosign has quikcly risen to become the defacto container signing solution. This RFC proposes that we natively add cosign support to the lifecycle to facilitate easy signed container artifacts as part of the build process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Supply chain security has been on top of everyone's minds in 2021. It is important to ensure the integrity and origin of software artifacts in order to have a secure supply chain. Sigstore's cosign has quikcly risen to become the defacto container signing solution. This RFC proposes that we natively add cosign support to the lifecycle to facilitate easy signed container artifacts as part of the build process. | |
Supply chain security has been on top of everyone's minds in 2021-2022. It is important to ensure the integrity and origin of software artifacts in order to have a secure supply chain. Sigstore's cosign has quikcly risen to become the defacto container signing solution. This RFC proposes that we natively add cosign support to the lifecycle to facilitate easy signed container artifacts as part of the build process. |
😜
I would prefer if this was a repo under buildpacks org, potentially under the platform team since pack would be the first target usecase. It would make it easier to manage/review/depend on repositories that fall under the buildpacks org umbrella. |
Is the only outstanding issue of how we proceed with a PoC/where the work happens? |
Pretty much |
[spec-changes]: #spec-changes | ||
|
||
|
||
Noted above. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand this remark. Are there spec changes involved in this RFC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also a leftover.
# Motivation | ||
[motivation]: #motivation | ||
|
||
Supply chain security has been on top of everyone's minds in 2021. It is important to ensure the integrity and origin of software artifacts in order to have a secure supply chain. Sigstore's cosign has quikcly risen to become the defacto container signing solution. This RFC proposes that we natively add cosign support to the lifecycle to facilitate easy signed container artifacts as part of the build process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this "native"? From what I last recall, this was going to follow the same path as preparer and publisher where it wouldn't be a part of the lifecycle per se.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, it's a leftover from the old rfc. Will clean it up.
@samj1912 as we discussed, this RFC requires a few set of changes to align with the latest agreed upon strategy. Please let me know when it's updated and I'll review/start the voting period. |
@samj1912 what is the status of this RFC? Is this still something we want to do? |
- Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC) | ||
|
||
# Summary | ||
[summary]: #summary |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This RFC supports indeed to sign an existing SBoM but also to export the attestation or attachment. Summary text should be reviewed
- Verify that it has read access to the registries where the output images from `exporter` are stored and that their digests match the ones in `report.toml` | ||
- Verify that it has write access to the registries where it needs to output the signatures and attestations. | ||
- Generate cosign signatures for all the images along with the provided annotations. | ||
- If `export-sbom` is set to a value not equal to `none`, export the sbom accordingly as a cosign attestation or an attachment depending on the value. The default value is `attestation`. The SBOM will be fetched from the output image in the registry stored as defined in the platform API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where will the attestation or SBom file (= attachement I suppose ?) been exported ?
Signed-off-by: Sambhav Kothari skothari44@bloomberg.net
Fixes #192
Readable
Debatable points -