Set Source information in ResolutionRequest #5522

chuangw6 · 2022-09-19T19:05:39Z

Feature request

We need to enable Resolvers to capture the correct ConfigSource information in ResolutionRequest that identifies the source where the remote resource came from. This needs to be done for the following cases:

git resolver
oci bundle resolver
hub resolver
remote cluster resolver
local cluster resolver (TBD)

Use case

SLSA provenance is required to capture the source of the remote config files in predicate.invocation.configSource section in which three fields are required: url, revision (actual commit sha) and path in source. Therefore, we need to capture the correct source information in resolvers because the moment of resolving the remote source is the time we know the source of truth. When the source information is captured in ResolutionRequest status, we will be able to pass this information to pipeline reconciler that will set the value in TaskRun/PipelineRun status so that Chains can capture the information from *Run.status.

Implementation

Git resolver: Set ConfigSource in gitresolver #5664
Bundle resolver: Set ConfigSource in bundleresolver #5684
Hun resolver: part of [TEP-0115] Support Artifact Hub in Hub Resolver #5666
Cluster resolver: Set ConfigSource in clusterresolver #5687

The text was updated successfully, but these errors were encountered:

chuangw6 · 2022-09-19T19:06:26Z

/assign

…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <chuangw@google.com>

Prior, remote `ResolutionRequest` CRD supports **recording** the source information in its Status that identifies where the remote resource came from. Similarly, `TaskRun/PipelineRun` CRD supports **receiving** the source information via a field in its status from remote ResolutionRequest. Specifically, this field named `ConfigSource` is a subfield of the `Provenance` field in status. In this PR, we are trying to pass the data from `ResolutionRequest` to pipeline reconciler so that the data can be captured in TaskRun/PipelineRun's `Status.Provenance.ConfigSource`. The implication of this change is that many functions' interface has been changed because we are passing this extra source data alongside the remote resoure. Note: - The `provenance` field in Run.status is behind a feature flag named `enable-provenance-in-status` , which was introduced in tektoncd#5670. The field will be populated iff the flag is set to `true`. - If a pipeline yaml is from remote place A, and the individual tasks are from other remote places, pipelinerun status will only record the source for the pipeline, and the individual taskrun status will record the source for the corresponding task. Related PRs/Issues: - tektoncd#5580 - tektoncd#5551 - tektoncd#5670 - tektoncd#5522 Signed-off-by: Chuang Wang <chuangw@google.com>

Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: in-cluster CRD resource URI in the format of the [namespace-scoped resources](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris). Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: sha256 checksum of the in-cluster resource - entrypoint: ***empty** because the path is already available in url field. Signed-off-by: Chuang Wang <chuangw@google.com>

Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: in-cluster CRD resource URI in the format of the [namespace-scoped resources](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris). Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <chuangw@google.com>

Prior, remote `ResolutionRequest` CRD supports **recording** the source information in its Status that identifies where the remote resource came from. Similarly, `TaskRun/PipelineRun` CRD supports **receiving** the source information via a field in its status from remote ResolutionRequest. Specifically, this field named `ConfigSource` is a subfield of the `Provenance` field in status. In this PR, we are trying to pass the data from `ResolutionRequest` to pipeline reconciler so that the data can be captured in TaskRun/PipelineRun's `Status.Provenance.ConfigSource`. The implication of this change is that many functions' interface has been changed because we are passing this extra source data alongside the remote resoure. Note: - The `provenance` field in Run.status is behind a feature flag named `enable-provenance-in-status` , which was introduced in tektoncd#5670. The field will be populated iff the flag is set to `true`. - If a pipeline yaml is from remote place A, and the individual tasks are from other remote places, pipelinerun status will only record the source for the pipeline, and the individual taskrun status will record the source for the corresponding task. Related PRs/Issues: - tektoncd#5580 - tektoncd#5551 - tektoncd#5670 - tektoncd#5522 Signed-off-by: Chuang Wang <chuangw@google.com>

Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <chuangw@google.com>

Prior, remote `ResolutionRequest` CRD supports **recording** the source information in its Status that identifies where the remote resource came from. Similarly, `TaskRun/PipelineRun` CRD supports **receiving** the source information via a field in its status from remote ResolutionRequest. Specifically, this field named `ConfigSource` is a subfield of the `Provenance` field in status. In this PR, we are trying to pass the data from `ResolutionRequest` to pipeline reconciler so that the data can be captured in TaskRun/PipelineRun's `Status.Provenance.ConfigSource`. The implication of this change is that many functions' interface has been changed because we are passing this extra source data alongside the remote resoure. Note: - The `provenance` field in Run.status is behind a feature flag named `enable-provenance-in-status` , which was introduced in tektoncd#5670. The field will be populated iff the flag is set to `true`. - If a pipeline yaml is from remote place A, and the individual tasks are from other remote places, pipelinerun status will only record the source for the pipeline, and the individual taskrun status will record the source for the corresponding task. Related PRs/Issues: - tektoncd#5580 - tektoncd#5551 - tektoncd#5670 - tektoncd#5522 Signed-off-by: Chuang Wang <chuangw@google.com>

Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <chuangw@google.com>

Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: hex-encoded sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <chuangw@google.com>

Prior, remote `ResolutionRequest` CRD supports **recording** the source information in its Status that identifies where the remote resource came from. Similarly, `TaskRun/PipelineRun` CRD supports **receiving** the source information via a field in its status from remote ResolutionRequest. Specifically, this field named `ConfigSource` is a subfield of the `Provenance` field in status. In this PR, we are trying to pass the data from `ResolutionRequest` to pipeline reconciler so that the data can be captured in TaskRun/PipelineRun's `Status.Provenance.ConfigSource`. The implication of this change is that many functions' interface has been changed because we are passing this extra source data alongside the remote resoure. Note: - The `provenance` field in Run.status is behind a feature flag named `enable-provenance-in-status` , which was introduced in tektoncd#5670. The field will be populated iff the flag is set to `true`. - If a pipeline yaml is from remote place A, and the individual tasks are from other remote places, pipelinerun status will only record the source for the pipeline, and the individual taskrun status will record the source for the corresponding task. Related PRs/Issues: - tektoncd#5580 - tektoncd#5551 - tektoncd#5670 - tektoncd#5522 Signed-off-by: Chuang Wang <chuangw@google.com>

Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: hex-encoded sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <chuangw@google.com>

Related to #5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: hex-encoded sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <chuangw@google.com>

Prior, remote `ResolutionRequest` CRD supports **recording** the source information in its Status that identifies where the remote resource came from. Similarly, `TaskRun/PipelineRun` CRD supports **receiving** the source information via a field in its status from remote ResolutionRequest. Specifically, this field named `ConfigSource` is a subfield of the `Provenance` field in status. In this PR, we are trying to pass the data from `ResolutionRequest` to pipeline reconciler so that the data can be captured in TaskRun/PipelineRun's `Status.Provenance.ConfigSource`. The implication of this change is that many functions' interface has been changed because we are passing this extra source data alongside the remote resoure. Note: - The `provenance` field in Run.status is behind a feature flag named `enable-provenance-in-status` , which was introduced in tektoncd#5670. The field will be populated iff the flag is set to `true`. - If a pipeline yaml is from remote place A, and the individual tasks are from other remote places, pipelinerun status will only record the source for the pipeline, and the individual taskrun status will record the source for the corresponding task. Related PRs/Issues: - tektoncd#5580 - tektoncd#5551 - tektoncd#5670 - tektoncd#5522 Signed-off-by: Chuang Wang <chuangw@google.com>

Prior, remote `ResolutionRequest` CRD supports **recording** the source information in its Status that identifies where the remote resource came from. Similarly, `TaskRun/PipelineRun` CRD supports **receiving** the source information via a field in its status from remote ResolutionRequest. Specifically, this field named `ConfigSource` is a subfield of the `Provenance` field in status. In this PR, we are trying to pass the data from `ResolutionRequest` to pipeline reconciler so that the data can be captured in TaskRun/PipelineRun's `Status.Provenance.ConfigSource`. The implication of this change is that many functions' interface has been changed because we are passing this extra source data alongside the remote resoure. Note: - The `provenance` field in Run.status is behind a feature flag named `enable-provenance-in-status` , which was introduced in #5670. The field will be populated iff the flag is set to `true`. - If a pipeline yaml is from remote place A, and the individual tasks are from other remote places, pipelinerun status will only record the source for the pipeline, and the individual taskrun status will record the source for the corresponding task. Related PRs/Issues: - #5580 - #5551 - #5670 - #5522 Signed-off-by: Chuang Wang <chuangw@google.com>

tekton-robot · 2023-02-09T00:11:27Z

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 · 2023-03-11T00:26:02Z

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.

chuangw6 · 2023-03-13T13:34:13Z

/close

done!

tekton-robot · 2023-03-13T13:34:16Z

@chuangw6: Closing this issue.

In response to this:

/close

done!

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.

chuangw6 added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 19, 2022

tekton-robot assigned chuangw6 Sep 19, 2022

This was referenced Sep 19, 2022

Populate the *Run.Status.Provenance.ConfigSource field #5397

Merged

Add provenance-related field in ResolutionRequest.Status #5529

Closed

chuangw6 changed the title ~~Passing ref data from ResolutionRequest to taskrun/pipelinerun through status.Annotations~~ Passing remote source information from Resolvers to Run status. Sep 29, 2022

chuangw6 changed the title ~~Passing remote source information from Resolvers to Run status.~~ Passing ConfigSource from Resolvers to Run status. Oct 4, 2022

chuangw6 changed the title ~~Passing ConfigSource from Resolvers to Run status.~~ Set Source information in ResolutionRequest Oct 24, 2022

This was referenced Oct 25, 2022

Set ConfigSource in bundleresolver #5684

Merged

Set ConfigSource in gitresolver #5664

Merged

chuangw6 mentioned this issue Nov 16, 2022

Chains needs to be able to "Identify entry point" - SLSA L3 requirement. tektoncd/chains#521

Closed

wlynch mentioned this issue Nov 23, 2022

TEP-0122 complete build instructions and parameters tektoncd/community#820

Merged

tekton-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 9, 2023

tekton-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Mar 11, 2023

tekton-robot closed this as completed Mar 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Set Source information in ResolutionRequest #5522

Set Source information in ResolutionRequest #5522

chuangw6 commented Sep 19, 2022 •

edited

chuangw6 commented Sep 19, 2022

tekton-robot commented Feb 9, 2023

tekton-robot commented Mar 11, 2023

chuangw6 commented Mar 13, 2023

tekton-robot commented Mar 13, 2023

Set Source information in ResolutionRequest #5522

Set Source information in ResolutionRequest #5522

Comments

chuangw6 commented Sep 19, 2022 • edited

Feature request

Use case

Implementation

chuangw6 commented Sep 19, 2022

tekton-robot commented Feb 9, 2023

tekton-robot commented Mar 11, 2023

chuangw6 commented Mar 13, 2023

tekton-robot commented Mar 13, 2023

chuangw6 commented Sep 19, 2022 •

edited