-
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?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
@@ -0,0 +1,100 @@ | ||||||||||
# Meta | ||||||||||
[meta]: #meta | ||||||||||
- Name: Cosign support | ||||||||||
- Start Date: 2021-12-03 | ||||||||||
- Author(s): [@samj1912](https://github.com/samj1912) | ||||||||||
- RFC Pull Request: (leave blank) | ||||||||||
- CNB Pull Request: (leave blank) | ||||||||||
- CNB Issue: (leave blank) | ||||||||||
- Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC) | ||||||||||
|
||||||||||
# Summary | ||||||||||
[summary]: #summary | ||||||||||
|
||||||||||
Adds image signing support to Buildpacks natively using cosign. | ||||||||||
|
||||||||||
# Definitions | ||||||||||
[definitions]: #definitions | ||||||||||
|
||||||||||
- cosign: A sigstore project to sign container images - https://github.com/sigstore/cosign | ||||||||||
- SBOM: Software Bill-of-Materials | ||||||||||
|
||||||||||
|
||||||||||
# 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 commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
😜 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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. |
||||||||||
|
||||||||||
# What it is | ||||||||||
[what-it-is]: #what-it-is | ||||||||||
|
||||||||||
An new phase `signer` which can be optionally run after the `exporter` if the image was exported to an OCI registry. The `signer` takes in the `report.toml` produced by the `exporter` and a `cosign.toml` file as flags. The interface would look like `/cnb/signer -report <report.toml> -cosign-config <cosign.toml>`. | ||||||||||
|
||||||||||
The schema for `cosign.toml` will look like the following - | ||||||||||
|
||||||||||
```toml | ||||||||||
# A static list of annotations to add to each signature config | ||||||||||
[[annotations]] | ||||||||||
name = "<name>" | ||||||||||
value = "<value>" | ||||||||||
|
||||||||||
[[annotations]] | ||||||||||
name = "<name2>" | ||||||||||
value = "<value2>" | ||||||||||
|
||||||||||
# multiple cosign configs can be specified | ||||||||||
[[configs]] | ||||||||||
# path to private key | ||||||||||
key = "<path-to-key>" | ||||||||||
# optional value for COSIGN_REPOSITORY, optional, default:"" | ||||||||||
repository = "<cosign-repository>" | ||||||||||
# value for COSIGN_DOCKER_MEDIA_TYPES, optional, default:false | ||||||||||
docker-media-types = true | ||||||||||
# optional path to password file. Contents will be used as COSIGN_PASSWORD | ||||||||||
password = "<path-to-password-file>" | ||||||||||
# optional flag to export sbom as attestations or attachement if SBOM is present in the 0.7+ format, default:attestation. | ||||||||||
export-sbom = `none|attestation|attachment` | ||||||||||
``` | ||||||||||
The `signer` will do the following - | ||||||||||
|
||||||||||
- 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 commentThe reason will be displayed to describe this comment to others. Learn more. Where will the attestation or SBom file (= attachement I suppose ?) been exported ? |
||||||||||
|
||||||||||
# How it Works | ||||||||||
[how-it-works]: #how-it-works | ||||||||||
|
||||||||||
The `signer` can use `cosign` as a library to generate, attach and publish signatures for the output image. `cosign` exposes a GGCR compatible interface which should fit nicely with the lifecycle. | ||||||||||
|
||||||||||
|
||||||||||
# Drawbacks | ||||||||||
[drawbacks]: #drawbacks | ||||||||||
|
||||||||||
Increased complexity in lifecycle | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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 commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more. If this moves outside There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Probably not... but in this case |
||||||||||
|
||||||||||
# Alternatives | ||||||||||
[alternatives]: #alternatives | ||||||||||
|
||||||||||
Add cosign support to pack. | ||||||||||
|
||||||||||
|
||||||||||
# Prior Art | ||||||||||
[prior-art]: #prior-art | ||||||||||
|
||||||||||
- https://github.com/buildpacks/pack/issues/268 | ||||||||||
- https://github.com/buildpacks/pack/issues/934 | ||||||||||
- https://github.com/pivotal/kpack/blob/main/rfcs/0007-cosign-integration.md | ||||||||||
|
||||||||||
|
||||||||||
# Unresolved Questions | ||||||||||
[unresolved-questions]: #unresolved-questions | ||||||||||
|
||||||||||
|
||||||||||
How to deal with daemon case? I am of the opinion that we should deprecate daemon flag in lifecycle and instead switch to OCI but that can come later. | ||||||||||
|
||||||||||
# Spec. Changes (OPTIONAL) | ||||||||||
[spec-changes]: #spec-changes | ||||||||||
|
||||||||||
|
||||||||||
Noted above. | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more. Also a leftover. |
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