Draft: SBOM refactor for registry images#298
Conversation
|
Maintainers, As you review this RFC please queue up issues to be created using the following commands: Issues(none) |
|
|
||
| ## Next builds | ||
|
|
||
| During `analyze`, the lifecyle should verify attestations for the previous application image, and download the SBOM data as files in `<layers>/sbom/launch/` |
There was a problem hiding this comment.
If there is an SBOM in the registry for the run image, we could do interesting things, like provide that to buildpacks (somehow, somewhere) so they could know more about what's available. But that should probably be out of scope for now.
text/0000-refactor-sbom.md
Outdated
There was a problem hiding this comment.
Examples here would be nice
|
|
||
| The `exporter` will accept a new optional flag `-omit-sbom` that defaults to `false`. | ||
| * If `-omit-sbom=false` the exporter will behave as today, and include the SBOM layer containing the `<layers>/sbom/launch/` directory in the application image. | ||
| * If `-omit-sbom=true` the exporter will not create the SBOM layer, but `<layers>/sbom/launch/` will remain on the filesystem and be available to the `signer`. |
There was a problem hiding this comment.
If -daemon is true we might log a warning or error
|
|
||
| ### Example 3 - platform-provided SBOM file | ||
|
|
||
| Platforms could inject TOML to describe the run image, e.g.: |
There was a problem hiding this comment.
This could be concatenated to the configuration file output by the exporter
natalieparellano
force-pushed
the
refactor-sbom
branch
from
699eee3 to
0e42bfc
Compare
Signed-off-by: Natalie Arellano <narellano@vmware.com>
natalieparellano
force-pushed
the
refactor-sbom
branch
from
0e42bfc to
be4fb90
Compare
|
Couple thoughts:
|
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
natalieparellano
changed the title
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
AidanDelaney
left a comment
AidanDelaney
left a comment
There was a problem hiding this comment.
In general, this looks good to me. I have one query as to whether we expect signer to write to a registry, or if it is generating an on-disk signature that exporter will export (I'm assuming the latter from the examples provided).
| We should explore secure ways of allowing the platform to inject this data (TODO). | ||
| It's worth noting that `cosign` as of v2 prefers keyless signing. | ||
|
|
||
| The `signer` can both sign the image and attach attestations to it. By default, we should do both - but we may want to make this configurable. |
There was a problem hiding this comment.
signer is then a registry operation? This means that both signer and exporter now write to the registry?
| ## Setup | ||
|
|
||
| The lifecycle will ship with a new `signer` binary. | ||
| In the past we've talked about making this binary totally separate from the lifecycle, |
There was a problem hiding this comment.
From 10/5 Working Group - cosign is nevertheless a significant dependency to take into the lifecycle. If cosign took a configuration file (sigstore/cosign#1288 or similar) maybe we could just set that configuration up according to the mapping defined below. That would take care of the signing part.
For retrieving SBOMs from the previous image, we could:
- explore making verifying attestations the responsibility of the "preparer" binary, if we ever have one; the preparer could write the predicate data as json for the analyzer to find
- put this in the analyzer and hope the dependency footprint would be smaller if we're only verifying signatures (not creating them)
|
|
||
| The exporter will additionally generate configuration for the `signer` irrespective of the value of `-omit-sbom`. | ||
|
|
||
| ## Sign |
There was a problem hiding this comment.
From 10/5 Working Group - adding signatures could be a big jump for platforms that just want to get the SBOM out of the application image. We could provide an option to generate unsigned attestations as OCI artifacts in the registry which might ease the migration path for some folks.
|
|
||
| TODO | ||
|
|
||
| Discuss prior art, both the good and bad. |
There was a problem hiding this comment.
Maybe the current cosign implementation in kpack could be referenced here?
5 participants
Readable