Record `invocation.configSource` section in slsa provenance

[chuangw6]

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

[tekton-robot]

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

[tekton-robot]

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

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[chuangw6]

/hold

waiting for https://github.com/tektoncd/pipeline/pull/5397

[lcarva]

@chuangw6, I remember a comment from @priyawadhwa that if we populate configSource, we shouldn't update buildConfig. Maybe I misunderstood the comment?

[chuangw6]

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

[priyawadhwa]

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!

[chuangw6]

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!

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?

[chuangw6]

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.

[priyawadhwa]

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.

[chuangw6]

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.

[tekton-robot]

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

[tekton-robot]

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

[chuangw6]

/unhold

[tekton-robot]

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

[tekton-robot]

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

[tekton-robot]

[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

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [wlynch]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment