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
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
100 changes: 100 additions & 0 deletions text/0000-cosign.md
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

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


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

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.

😜

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.


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

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 ?


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


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