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 RFC for cosign integration #195

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

sambhav
Copy link
Member

@sambhav sambhav commented Dec 3, 2021

Signed-off-by: Sambhav Kothari skothari44@bloomberg.net

Fixes #192

Readable

Debatable points -

  • Dealing with daemon use case?
  • pack v/s lifecycle support?
  • SBOM future (for now this just exports the SBOM in cosign format but also continues to use the existing way of storing it in the app image for restore/rebuild)

@sambhav sambhav requested a review from a team as a code owner December 3, 2021 02:11
@buildpack-bot
Copy link
Member

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

(none)

@dlorenc
Copy link

dlorenc commented Dec 3, 2021

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.

text/0000-cosign.md Outdated Show resolved Hide resolved
@hone hone requested review from hone, jkutner and nebhale December 8, 2021 19:42
# 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Member

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?

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 ?

Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

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.

text/0000-cosign.md Outdated Show resolved Hide resolved
@hone hone requested a review from ekcasey January 12, 2022 19:44
text/0000-cosign.md Outdated Show resolved Hide resolved
Signed-off-by: Sambhav Kothari <skothari44@bloomberg.net>
Copy link
Member

@jromero jromero left a 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

😜

@hone hone added team/platform scope/team RFC scoped to a sub-team as opposed to the entire project. and removed team/implementation labels Mar 23, 2022
@sambhav
Copy link
Member Author

sambhav commented Mar 24, 2022

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?

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.

@hone
Copy link
Member

hone commented Apr 6, 2022

Is the only outstanding issue of how we proceed with a PoC/where the work happens?

@sambhav
Copy link
Member Author

sambhav commented Apr 6, 2022

Is the only outstanding issue of how we proceed with a PoC/where the work happens?

Pretty much

@sambhav sambhav requested a review from jromero April 8, 2022 18:59
[spec-changes]: #spec-changes


Noted above.
Copy link
Member

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?

Copy link
Member Author

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.
Copy link
Member

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.

Copy link
Member Author

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.

@jromero
Copy link
Member

jromero commented May 27, 2022

@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.

@natalieparellano
Copy link
Member

@samj1912 what is the status of this RFC? Is this still something we want to do?

@sambhav sambhav mentioned this pull request Feb 26, 2023
@natalieparellano natalieparellano added scope/project and removed scope/team RFC scoped to a sub-team as opposed to the entire project. labels Mar 1, 2023
- Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC)

# Summary
[summary]: #summary

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.

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Idea: Add support for cosign