TEP-0122 complete build instructions and parameters #820
Conversation
tekton-robot
added
do-not-merge/work-in-progress
chitrangpatel
force-pushed
the
TEP-0122-reproducibility-of-complete-build-instructions
branch
3 times, most recently
from
a94d563
to
df8d557
Compare
tekton-robot
added
size/L
chitrangpatel
force-pushed
the
TEP-0122-reproducibility-of-complete-build-instructions
branch
7 times, most recently
from
18d4a0f
to
406d659
Compare
tekton-robot
removed
the
do-not-merge/work-in-progress
|
/assign @wlynch |
|
cc @chuangw6 |
|
/kind tep |
tekton-robot
added
the
kind/tep
|
/assign @vdemeester |
chitrangpatel
force-pushed
the
TEP-0122-reproducibility-of-complete-build-instructions
branch
2 times, most recently
from
3dd2f19
to
94de42b
Compare
|
API WG - ready for review, please take a look 🙏 |
There was a problem hiding this comment.
I had initially suggested we frame these changes around 'reproducibility' but I think that has caused some confusion (since the SLSA reproducible requirement requires very little from the build platform and I don't think we should try to go beyond that at least for now) and I think we are actually trying to meet two other SLSA provenance requirements:
I think it boils down to something like this:
- 'build instructions' for Tekton are the 'authoring time info' i.e. the Task/Pipeline defintion
- 'build parameters' for Tekton are the 'runtime info' that is provided (i.e. the info a TaskRun/PipelineRun provides in order to realize execution of at Task/Pipeline)
Our 'build instructions' are currently incomplete (or were 6 months ago anyway XD) b/c we just grab the steps and not the entire Task definition (and we need to now include Pipeline definitions for PipelineRun level provenance). If "build as code" is used, the SLSA requirement is just that we identify where the Task/Pipeline lives in version control. If it isn't, we need to reproduce the Task/Pipeline in the provenance (we can decide if we want to include it in the build as code case as well).
We also need to make sure we are including all of the param/runtime info as well. (You're probably right to include the invocation.environment info here as well BUT I think you would also be reasonable to declare that out of scope and tackle is separately)
So TL;DR, if you agree, for clarity I'd personally rename this TEP to something like "complete build instructions and parameters" - and maybe remove requirements around reproducibility as well.
I can certainly do that. Things around that are creating a lot of confusion and raising questions that probably cannot be answered immediately.
Sounds good. Updated the TEP to reflect your suggestions. Let me know what you think. |
chitrangpatel
force-pushed
the
TEP-0122-reproducibility-of-complete-build-instructions
branch
2 times, most recently
from
47ab991
to
ba5d586
Compare
chitrangpatel
changed the title
chitrangpatel
force-pushed
the
TEP-0122-reproducibility-of-complete-build-instructions
branch
from
ba5d586
to
b95cca4
Compare
tekton-robot
added
the
approved
| - For completeness of build instructions, the provenance should contain all of the Task definition and runtime information. | ||
| - The shas of the images run should continue to be included regardless (as this is part of the dependencies / build instructions) | ||
| - It must be possible for users to construct policies based on the provenance that would allow them to determine if the build is ok - for example if they have policies around what pipeline tasks are acceptable to use, what parameters are acceptable, whether or not sidecars are allowed etc. | ||
| - According to [SLSA v0.2](https://slsa.dev/provenance/v0.2), if **invocation.configSource** is not available then **buildConfig** can be used to verify information about the build. If the policy requires validating the underlying task/pipeline spec that was not fetched from version control then the information from the spec required for validation must be embedded in the provenance’s buildConfig. |
There was a problem hiding this comment.
If I understand this correctly, when the resource definition is not coming from a versioned source, we use buildConfig to store it directly in the provenance, correct?
Would it make sense later on in the spec to specify the list of sources that are considered ok for configSource?
There was a problem hiding this comment.
If I understand this correctly, when the resource definition is not coming from a versioned source, we use buildConfig to store it directly in the provenance, correct?
Yes, that is correct.
Would it make sense later on in the spec to specify the list of sources that are considered ok for configSource?
My understanding is that SLSA needs the references need to be immutable. We support three: GitHub, OCI bundles and hub.
This proposal outlines what information is required in the provenance to reproduce complete build instructions for task runs. It also suggests where in the provenance to store this information.
chitrangpatel
force-pushed
the
TEP-0122-reproducibility-of-complete-build-instructions
branch
from
b95cca4
to
9aed990
Compare
|
Looks great, thanks @chitrangpatel ! /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli, bobcatfish, wlynch The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
From WG on Dec 5th |
This proposal outlines what information is required to reproduce complete build instructions for taskruns. It also suggests where in the provenance to store this information.