chains
chains copied to clipboard
Record `invocation.configSource` section in slsa provenance
Changes
Related to https://github.com/tektoncd/chains/issues/521 and https://github.com/tektoncd/pipeline/pull/5397
Prior to this PR, invocation.configSource
section in slsa provenance was missing.
In this change, we want to record the configSource information in the provenance for the remote resources i.e. git, bundle, catalog.
Signed-off-by: Chuang Wang [email protected]
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
- [ ] Has Docs included if any changes are user facing
- [ ] Has Tests included if any functionality added or changed
- [ ] Follows the commit message standard
- [ ] Meets the Tekton contributor standards (including functionality, content, code)
- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
- [ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release
Release Notes
NONE
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign lukehinds after the PR has been reviewed.
You can assign the PR to them by writing /assign @lukehinds
in a comment when ready.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve
in a comment
Approvers can cancel approval by writing /approve cancel
in a comment
/hold
waiting for https://github.com/tektoncd/pipeline/pull/5397
@chuangw6, I remember a comment from @priyawadhwa that if we populate configSource, we shouldn't update buildConfig. Maybe I misunderstood the comment?
@chuangw6, I remember a comment from @priyawadhwa that if we populate configSource, we shouldn't update buildConfig. Maybe I misunderstood the comment?
Yeah, I remember that. Talking to @wlynch before, it seems fine to include both sections if we do want to record the remote refs in the provenance.
Thoughts @priyawadhwa @wlynch?
I'd prefer the provenance be as correct as possible based on the spec. If we can correctly set configSource
we shouldn't need buildConfig
anymore!
I'd prefer the provenance be as correct as possible based on the spec. If we can correctly set
configSource
we shouldn't needbuildConfig
anymore!
That makes sense to me as long as we still record the param values provided by taskrun/pipeline run in the invocation.parameters
section. So we can
- record
buildConfig
section only for embedded and incluster definition. - record
invocation.configSource
section only for remote resources (git, oci, catalog).
But one case I am concerned about is what if the remote resource that user specified in resolver is not retrievable later for some reason. For example, a user specifies git url, commit and pathInRepo correctly in taskrun definition -> taskrun reconciler fetches the resource -> Chains records it in invocation.configSource
and leaves buildConfig
empty -> later the repo that contains the task definition is deleted. In this case, the information recorded in invocation.configSource
or say the whole provenance will be meaningless. wdyt?
Seems like the slsa0.2 spec doesn't explicitly say the configSource
and buildConfig
shouldn't exist simultaneously. In the Cloud Build example listed on the website, both sections are filled with content.
That makes sense to me as long as we still record the param values provided by taskrun/pipeline run in the invocation.parameters section.
SGTM.
Re the Cloud Build example, my guess is the example isn't entirely accurate (the Cloud Build RPC example does specify // Build steps were provided as an argument. No configSource
). The definition for buildConfig
is:
Lists the steps in the build. If invocation.configSource is not available, buildConfig can be used to verify information about the build.
and when I added buildConfig
into the v0.2 spec a few months ago it was definitely intended as an alternative to configSource
. I don't really see a use case for having both (if a repo is deleted I'd guess you probably just wouldn't trust the artifact at all), but if you feel strongly we can give it a try.
Thanks for the details @priyawadhwa !
I feel like it might be necessary to always keep buildConfig
section for at least auditing purpose and also for helping reproduce a build. Although we set invocation.configSource
correctly for the remote definitions, it's possible that the consumer of the provenance does not have the access to the remote repo especially the gitresolver recently supports fetching files from a private repo in https://github.com/tektoncd/pipeline/pull/5450.
@chuangw6: PR needs rebase.
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.
The following is the coverage report on the affected files.
Say /test pull-tekton-chains-go-coverage
to re-run this coverage report
File | Old Coverage | New Coverage | Delta |
---|---|---|---|
pkg/chains/formats/intotoite6/pipelinerun/pipelinerun.go | 77.3% | 78.7% | 1.5 |
pkg/chains/formats/intotoite6/taskrun/taskrun.go | 76.5% | 76.1% | -0.4 |
/unhold
The following is the coverage report on the affected files.
Say /test pull-tekton-chains-go-coverage
to re-run this coverage report
File | Old Coverage | New Coverage | Delta |
---|---|---|---|
pkg/chains/formats/intotoite6/pipelinerun/pipelinerun.go | 77.3% | 78.7% | 1.5 |
pkg/chains/formats/intotoite6/taskrun/taskrun.go | 76.5% | 76.1% | -0.4 |
The following is the coverage report on the affected files.
Say /test pull-tekton-chains-go-coverage
to re-run this coverage report
File | Old Coverage | New Coverage | Delta |
---|---|---|---|
pkg/chains/formats/intotoite6/pipelinerun/pipelinerun.go | 77.3% | 78.7% | 1.5 |
pkg/chains/formats/intotoite6/taskrun/taskrun.go | 76.5% | 76.1% | -0.4 |
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: wlynch
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [wlynch]
Approvers can indicate their approval by writing /approve
in a comment
Approvers can cancel approval by writing /approve cancel
in a comment