SLSA version in Tekton Chains

[chuangw6]

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.

[chuangw6]

cc @wlynch @priyawadhwa

[chuangw6]

Concern

While supporting the latest SLSA provenance, we should avoid breaking the users/consumers who are still relying on the older SLSA version.

Proposal

1. Chains generates one intoto statement per SLSA version (that is, each intoto statement contains a specific version of SLSA predicate).
2. To support 1/, Chains needs to use the generic Statement struct rather than the SLSA0.2-specific ProvenanceStatement struct from the in-toto-golang package.

[priyawadhwa]

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

[wlynch]

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?

[priyawadhwa]

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

[chuangw6]

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

[priyawadhwa]

If we introduce the new formats.in-toto.version field, is it just an auxiliary field for the existing artifacts.taskrun.format field?

Yes!

• 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

Yah, exactly!

[chuangw6]

SGTM! Thanks for the confirmation. @priyawadhwa

[chuangw6]

/assign

[tekton-robot]

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.

[tekton-robot]

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.

[tekton-robot]

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]

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