chains
chains copied to clipboard
SLSA version in Tekton Chains
Currently Tekton Chains generates intoto statement with SLSA 0.2 predicate. However, we might expect breaking changes from SLSA version v0.X to v1.0 according to the official doc since it is constantly evolving (SLSA roadmap).
Note about 0.x versions We expect regular iteration on 0.x versions until 1.0. During 0.x, we lean towards smaller, faster releases in order to get earlier feedback on the design. After 1.0, we will limit the frequency of breaking changes. To make this manageable, we recommend that:
- Provenance generators choose the latest 0.x version at the time of implementation and then stick with that until 1.0 unless there is reason to upgrade before then.
- Provenance consumers accept all known versions and convert internally between them.
This issue is to track supporting SLSA v1 provenance in Chains.
If you have any questions, comments or concerns on the SLSA version changes in Chains, feel free to add them here.
cc @wlynch @priyawadhwa
Concern
While supporting the latest SLSA provenance, we should avoid breaking the users/consumers who are still relying on the older SLSA version.
Proposal
- Chains generates one intoto statement per SLSA version (that is, each intoto statement contains a specific version of SLSA predicate).
- To support 1/, Chains needs to use the generic
Statement
struct rather than the SLSA0.2-specificProvenanceStatement
struct from the in-toto-golang package.
Instead of generating a statement for all SLSA versions, could we have users specify which version they want via the config? Maybe something like
formats.in-toto.version = v0.2
and it would default to latest
Chatted with @chuangw6 about this a bit last week - I think we landed on a similar idea to yours @priyawadhwa! The alternative we were thinking of was allowing multiple values in the existing artifacts.*.format
field, i.e. intoto-v0.2
, intoto-v1
, with the existing intoto
value just being an alias to the latest version. Thinking about it more now, I think your approach might be better to add in a backwards compatible way (I'm not sure if we can move from string -> list without client config changes).
The other wrinkle to this is wanting to support multiple versions for phased rollouts. I agree we should avoid supporting all versions forever, but supporting a configured set seems reasonable for cases like upgrades. i.e. when we want to add SLSA v1, allow Chains to optionally write v0.2 and v1 (choose to pin to 1 version, or allow writing both), then turn down v0.2 once we consider v1 to be stable. wdyt?
SGTM! We can support latest and maybe the 1-2 most recent versions as well, and just document that policy somewhere.
If we introduce a new formats.in-toto.version
field then it can be a list from the start so users can still generate multiple attestations at different versions if they want to
Just want to clarify:
If we introduce the new formats.in-toto.version
field, is it just an auxiliary field for the existing artifacts.taskrun.format
field?
To put it differently, users still need to configure the in-toto
option for the artifacts.taskrun.format
field. And when we see in-toto
is selected, we check formats.in-toto.version
:
- If formats.in-toto.version
is empty or intoto-v1
, we only generate the latest version.
- If formats.in-toto.version
is a list i.e. intoto-v0.2,intoto-v1
, we will generate multiple versions.
Is that the idea? @priyawadhwa @wlynch
If we introduce the new
formats.in-toto.version
field, is it just an auxiliary field for the existingartifacts.taskrun.format
field?
Yes!
- If
formats.in-toto.version
is empty orintoto-v1
, we only generate the latest version.- If
formats.in-toto.version
is a list i.e.intoto-v0.2,intoto-v1
, we will generate multiple versions
Yah, exactly!
SGTM! Thanks for the confirmation. @priyawadhwa
/assign
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
with a justification.
Mark the issue as fresh with /remove-lifecycle rotten
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/close
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen
with a justification. Mark the issue as fresh with/remove-lifecycle rotten
with a justification. If this issue should be exempted, mark the issue as frozen with/lifecycle frozen
with a justification./close
Send feedback to tektoncd/plumbing.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.