[TEP-0089] Enable the signing and verification of TR results and the TR status #6782

jagathprakash · 2023-06-06T23:05:40Z

Enable the signing and verification of TR results and the TR status.

This PR enables the signing and verification of TR results and TR status.

Before this change the spireAPIController object was injected into the TR reconciler but it was not used.

After this change,

At the start of every reconcile run, the reconciler will verify if the signature on the status can be verified, else it will error out.
At the end of every reconcile run, the reconciler will sign the status and add it as an annotation.
When TR results are read from the termination message and converted into TR results, they will be verified.

This commit is part of a series of PRs to implement TEP-0089. The implementation of TEP-0089 is tracked in the issue #6597 SPIRE for non-falsifiable provenance.

Changes

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
Has Tests included if any functionality added or changed
Follows the commit message standard
Meets the Tekton contributor standards (including functionality, content, code)
Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
[] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

* Added TaskRun Status annotations to track the validity of the signed TaskRun
* Utilizes pipeline controller spire SVID, status hash and signature
* Pipeline controller continuously validates the TaskRun Status for any modifications
* Tekton Chains will validate the results and status of the TaskRun after completion

tekton-robot · 2023-06-06T23:05:42Z

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

jagathprakash · 2023-06-06T23:06:06Z

/kind feature

jagathprakash · 2023-06-06T23:06:41Z

/assign @jerop @chuangw6

tekton-robot · 2023-06-06T23:12:36Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.7%	85.2%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

chuangw6 · 2023-06-12T19:01:31Z

@jagathprakash Can we add this PR to the tracking issue #6597? Thanks!

jagathprakash · 2023-06-12T22:07:13Z

@jagathprakash Can we add this PR to the tracking issue #6597? Thanks!

Done.

tekton-robot · 2023-06-13T15:38:50Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.7%	85.2%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-13T16:26:30Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from jerop after the PR has been reviewed.

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

tekton-robot · 2023-06-13T16:32:46Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.7%	85.2%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-13T16:34:05Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.7%	85.2%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-13T16:59:20Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.7%	85.2%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-13T17:00:30Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.7%	85.2%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

chitrangpatel · 2023-06-13T17:13:00Z

pkg/pod/status.go

 				if tr.IsDone() {
 					trs.TaskRunResults = append(trs.TaskRunResults, taskResults...)
+					if spireEnabled {


You might need to repeat this block after line 211 as well for status update after fetching results from sidecar logs.

Thats right. But signing itself is not done for results from sidecar logs. As such if we verify here, it will surely fail.
Results from sidecarlogs will be handled in a separate PR after this PR is done.

chitrangpatel · 2023-06-13T17:17:36Z

test/taskrun_test.go

+  - image: ubuntu
+    script: |
+      #!/usr/bin/env bash
+      sleep 20


why do we sleep for 20 seconds?

This is not needed but does no harm.
The TR hare has been copied from TestTaskRunModificationSpire where we need the 20sec sleep so that we can modify the TR while the TR is still sleeping and hence fail the task when SPIRE is enabled.

chuangw6 · 2023-06-13T19:10:53Z

/assign

wlynch · 2023-06-14T13:16:48Z

docs/spire.md

+
+ NAME                    VALUE
+ ∙ RESULT_MANIFEST       commit,url,SVID,commit.sig,url.sig
+ ∙ RESULT_MANIFEST.sig   MEUCIQD55MMII9SEk/esQvwNLGC43y7efNGZ+7fsTdq+9vXYFAIgNoRW7cV9WKriZkcHETIaAKqfcZVJfsKbEmaDyohDSm4=


Bit of an inconsistency here:

We document the result name format as:

Name must consist of alphanumeric characters, '-', '_', and must start and end with an alphanumeric character (e.g. 'MyName', or 'my-name', or 'my_name'

But the actual regex used allows for .

I'm not sure what happens if we try to consume a result with a . in the name - i.e. results.foo.sig.path, or a more confusing example with results.path.path.path 🤔

We should resolve this ambiguity before we start using the .sig suffix. /cc @tektoncd/core-maintainers

+1 to resolving this ambiguity. Though FWIW .sig works.
But still for this PR, we could change this _sig or -sig.
WDYT @wlynch

wlynch · 2023-06-14T13:27:41Z

pkg/reconciler/taskrun/taskrun.go

+				if tr.Status.Annotations == nil {
+					tr.Status.Annotations = map[string]string{}
+				}
+				tr.Status.Annotations[spire.VerifiedAnnotation] = "no"


Similar to status, should we include this annotation? 🤔

I'm not sure if it gives more information that isn't already available in the status.

Missing this annotation doesn't tell you if this is verified or not, and older tekton versions won't be setting this.

This annotation can be modified to not match the underlying state.

wlynch · 2023-06-14T13:36:35Z

pkg/pod/status.go

@@ -159,7 +164,28 @@ func MakeTaskRunStatus(ctx context.Context, logger *zap.SugaredLogger, tr v1beta
 	return *trs, merr.ErrorOrNil()
 }

-func setTaskRunStatusBasedOnStepStatus(ctx context.Context, logger *zap.SugaredLogger, stepStatuses []corev1.ContainerStatus, tr *v1beta1.TaskRun, podPhase corev1.PodPhase, kubeclient kubernetes.Interface, ts *v1beta1.TaskSpec) *multierror.Error {
+func setTaskRunStatusBasedOnSpireVerification(ctx context.Context, logger *zap.SugaredLogger, tr *v1beta1.TaskRun, trs *v1beta1.TaskRunStatus,


It's a little tricky to know what this is doing / modifying from just the function signature.

Should we change this to return a condition rather than mutating via the pointer?

Otherwise consider adding godoc to explain what's going on.

wlynch · 2023-06-14T13:37:57Z

pkg/pod/status.go

@@ -159,7 +164,28 @@ func MakeTaskRunStatus(ctx context.Context, logger *zap.SugaredLogger, tr v1beta
 	return *trs, merr.ErrorOrNil()
 }

-func setTaskRunStatusBasedOnStepStatus(ctx context.Context, logger *zap.SugaredLogger, stepStatuses []corev1.ContainerStatus, tr *v1beta1.TaskRun, podPhase corev1.PodPhase, kubeclient kubernetes.Interface, ts *v1beta1.TaskSpec) *multierror.Error {
+func setTaskRunStatusBasedOnSpireVerification(ctx context.Context, logger *zap.SugaredLogger, tr *v1beta1.TaskRun, trs *v1beta1.TaskRunStatus,


tr *v1beta1.TaskRun, trs *v1beta1.TaskRunStatus

Does tr.Status == trs? If so, do we need to pass in both values? If not, when can these differ?

wlynch · 2023-06-14T13:42:04Z

pkg/pod/status.go

+	trs.SetCondition(&apis.Condition{
+		Type:    apis.ConditionType(v1beta1.TaskRunConditionResultsVerified.String()),
+		Status:  corev1.ConditionTrue,
+		Reason:  v1beta1.TaskRunReasonResultsVerified.String(),
+		Message: "Successfully verified all spire signed taskrun results",
+	})


The status isn't really authoritative for verification since it could be tampered with. Instead of giving users a field that they may put more trust in than they should, should we just make it easy to verify the signatures from any client? e.g. if we wanted tkn to verify the signatures instead of the controller, how would we recommend people to do it?

wlynch · 2023-06-14T14:00:38Z

docs/spire.md

+3.  Modify TaskRun to sign and verify TaskRunStatus using SPIRE (done). 
+4.  Enabling Chains to verify the TaskRun Results.
+
+When the TaskRun result attestations feature is [enabled](./spire.md#enabling-taskrun-result-attestations) all TaskRuns will produce a signature alongside its results, which can then be used to validate its provenance. For example, a TaskRun result that creates user-specified results `commit` and `url` would look like the following. `SVID`, `RESULT_MANIFEST`, `RESULT_MANIFEST.sig`, `commit.sig` and `url.sig` are generated attestations by the integration of SPIRE and Tekton Controller.


What happens if a user tries to emit a result that conflicts with any of these fields or a .sig suffix?

Good point. Was discussing this with @chuangw6 and we thought we could a check at validation (validation webhook) to ensure that user does not add any results with name "*.sig", "RESULT_MANIFEST" and "SVID".

wlynch · 2023-06-14T14:07:19Z

pkg/pod/status_test.go

+				c.want.TaskRunStatusFields.Steps[0].ContainerState.Terminated.Message = s
+			}
+
+			logger, _ := logging.NewLogger("", "status")


You probably want https://pkg.go.dev/knative.dev/[email protected]/logging/testing#TestLogger - this will add any logs to the test context

wlynch · 2023-06-14T14:09:01Z

pkg/pod/status_test.go

+			if tr.Status.StartTime.Time != c.want.StartTime.Time {
+				t.Errorf("Expected TaskRun startTime to be unchanged but was %s", tr.Status.StartTime)
+			}


Consider modifying the time Comparer instead of doing another check.

wlynch · 2023-06-14T14:09:59Z

pkg/pod/status_test.go

+			kubeclient := fakek8s.NewSimpleClientset()
+			got, err := MakeTaskRunStatus(ctx, logger, tr, &c.pod, kubeclient, &v1beta1.TaskSpec{}, sc)
+			if err != nil {
+				t.Errorf("MakeTaskRunResult: %s", err)


Should this be Fatal (e.g. do you want the test to continue if we fail to make the status)?

wlynch · 2023-06-14T14:12:30Z

pkg/reconciler/taskrun/taskrun.go

@@ -507,6 +544,15 @@ func (c *Reconciler) reconcile(ctx context.Context, tr *v1beta1.TaskRun, rtr *re
 	}

 	if podconvert.SidecarsReady(pod.Status) {
+		if spireEnabled {
+			// TTL for the entry is in seconds
+			ttl := time.Duration(config.FromContextOrDefaults(ctx).Defaults.DefaultTimeoutMinutes) * time.Minute


What's the purpose of this TTL? Does it need to match the pod timeout?

What happens if the pod/task timeout != the default?

…TR status. This PR enables the signing and verification of TR results and TR status. Before this change the spireAPIController object was injected into the TR reconciler but it was not used. After this change, - At the start of every reconcile run, the reconciler will verify if the signature on the status can be verified, else it will error out. - At the end of every reconcile run, the reconciler will sign the status and add it as an annotation. - When TR results are read from the termination message and converted into TR results, they will be verified. This commit is part of a series of PRs to implement TEP-0089. The implementation of TEP-0089 is tracked in the issue tektoncd#6597 SPIRE for non-falsifiable provenance.

tekton-robot · 2023-06-19T15:14:47Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-19T15:17:23Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-19T16:20:07Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/taskrun_types.go	77.4%	73.2%	-4.1
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.8%	85.3%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-19T16:22:49Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/taskrun_types.go	77.4%	73.2%	-4.1
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.8%	85.3%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-19T16:39:35Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/taskrun_types.go	77.4%	73.2%	-4.1
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.8%	85.3%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-19T16:43:01Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/taskrun_types.go	77.4%	73.2%	-4.1
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.8%	85.3%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-19T18:41:24Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/taskrun_types.go	77.4%	73.2%	-4.1
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.8%	85.3%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-19T18:44:08Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/taskrun_types.go	77.4%	73.2%	-4.1
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.8%	85.3%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

…TR status. This PR enables the signing and verification of TR results and TR status. Before this change the spireAPIController object was injected into the TR reconciler but it was not used. After this change, - At the start of every reconcile run, the reconciler will verify if the signature on the status can be verified, else it will error out. - At the end of every reconcile run, the reconciler will sign the status and add it as an annotation. - When TR results are read from the termination message and converted into TR results, they will be verified. This commit is part of a series of PRs to implement TEP-0089. The implementation of TEP-0089 is tracked in the issue tektoncd#6597 SPIRE for non-falsifiable provenance.

tekton-robot · 2023-06-19T19:16:02Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/taskrun_types.go	77.4%	73.2%	-4.1
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.8%	85.3%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

tekton-robot · 2023-06-19T19:19:35Z

@jagathprakash: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-tekton-pipeline-build-tests	`48ce881`	link	true	`/test pull-tekton-pipeline-build-tests`

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

tekton-robot · 2023-06-19T19:27:09Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/taskrun_types.go	77.4%	73.2%	-4.1
pkg/pod/status.go	91.7%	91.7%	0.0
pkg/reconciler/taskrun/taskrun.go	84.8%	85.3%	0.5
pkg/spire/spire_mock.go	80.6%	79.8%	-0.8

chuangw6 · 2023-06-15T14:43:17Z

docs/spire.md

-4.  Modify Tekton Chains to verify the TaskRun Results.
+2.  Add a configMap which initializes SPIRE (done).
+3.  Modify TaskRun to sign and verify TaskRunStatus using SPIRE (done). 
+4.  Enabling Chains to verify the TaskRun Results.


Can we call out other TODOs here i.e. sign other CRD status, sidecar based results.

chuangw6 · 2023-06-15T14:52:21Z

docs/spire.md

+  - Verify the content of `RESULT_MANIFEST` with the field `RESULT_MANIFEST.sig` with the SVID public key
+  - Verify that there is a corresponding field for all items listed in `RESULT_MANIFEST` (besides SVID and `*.sig` fields)
+- Verify individual result fields
+  - For each of the items in the results, verify its content against its associated `.sig` field


In this step, should we also verify the name of the result is in the verified RESULT_MANIFEST list?

chuangw6 · 2023-06-15T14:56:29Z

docs/spire.md

+The spec and TaskRun annotations/labels are not signed when there are valid interactions from other controllers or users (i.e. cancelling taskrun).
+Editing the object annotations/labels or spec will not result in any unverifiable outcome of the status field.
+
+As the TaskRun progresses, the Pipeline Controller will reconcile the TaskRun object and continually verify the current hash against the `tekton.dev/status-hash-sig` before updating the hash to match the new status and creating a new signature.


Suggested change

As the TaskRun progresses, the Pipeline Controller will reconcile the TaskRun object and continually verify the current hash against the `tekton.dev/status-hash-sig` before updating the hash to match the new status and creating a new signature.

As the TaskRun progresses, the Pipeline Controller will reconcile the TaskRun object and continually verify the current hash against the signature in the annotation `tekton.dev/status-hash-sig` before updating the hash to match the new status and creating a new signature.

chuangw6 · 2023-06-23T15:29:37Z

pkg/pod/status.go

@@ -265,7 +295,7 @@ func createMessageFromResults(results []result.RunResult) (string, error) {
 // filterResults filters the RunResults and TaskResults based on the results declared in the task spec.
 // It returns a slice of any of the input results that are defined in the task spec, converted to TaskRunResults,
 // and a slice of any of the RunResults that don't represent internal values (i.e. those that should not be displayed in the TaskRun status.
-func filterResults(results []result.RunResult, specResults []v1.TaskResult) ([]v1.TaskRunResult, []result.RunResult) {
+func filterResults(results []result.RunResult, specResults []v1.TaskResult, spireEnabled bool) ([]v1.TaskRunResult, []result.RunResult) {


I am puzzled by the function itself and the doc. Is the first returned value supposed to be the results that users have declared and should show up in status, whereas the second returned value is supposed to be the internal results and not be displayed in the status?

If so, the description of 2nd returned value is confusing " and a slice of any of the RunResults that don't represent internal values (i.e. those that should not be displayed in the TaskRun status.".

chuangw6 · 2023-06-23T15:32:42Z

pkg/pod/status.go

+				if spireEnabled {
+					if r.Key == spire.KeySVID || r.Key == spire.KeyResultManifest || strings.HasSuffix(r.Key, spire.KeySignatureSuffix) {
+						filteredResults = append(filteredResults, r)
+						continue
+					}
+				}


Based on what you mentioned in the doc, "However, the verification materials are removed from the final results as part of the TaskRun status. It is stored in the termination messages (more details below):".
Sounds like those results that we generated for verification purpose are more like InternalTektonResultType. I am curious if we should have set those ResultType as InternalTektonResultType during the signing process

chuangw6 · 2023-06-23T15:45:06Z

pkg/spire/verify.go

@@ -33,13 +33,13 @@ import (

 	"github.com/pkg/errors"
 	"github.com/spiffe/go-spiffe/v2/workloadapi"
-	"github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1"
+	v1 "github.com/tektoncd/pipeline/pkg/apis/pipeline/v1"


I think we don't need alias here.

chuangw6 · 2023-06-26T14:52:21Z

pkg/pod/status.go

@@ -159,7 +165,28 @@ func MakeTaskRunStatus(ctx context.Context, logger *zap.SugaredLogger, tr v1.Tas
 	return *trs, merr.ErrorOrNil()
 }

-func setTaskRunStatusBasedOnStepStatus(ctx context.Context, logger *zap.SugaredLogger, stepStatuses []corev1.ContainerStatus, tr *v1.TaskRun, podPhase corev1.PodPhase, kubeclient kubernetes.Interface, ts *v1.TaskSpec) *multierror.Error {
+func setTaskRunStatusBasedOnSpireVerification(ctx context.Context, logger *zap.SugaredLogger, tr *v1.TaskRun, trs *v1.TaskRunStatus,
+	filteredResults []result.RunResult, spireAPI spire.ControllerAPIClient) {


what does filteredResults mean here?

chuangw6 · 2023-06-26T14:53:47Z

pkg/pod/status.go

+	if tr.IsSuccessful() && spireAPI != nil &&
+		((tr.Status.TaskSpec != nil && len(tr.Status.TaskSpec.Results) >= 1) || len(filteredResults) >= 1) {


This condition is a bit hard to understand. Can we break it down a bit? Maybe something that can be reused on line 183.
i.e.

hasResults := tr.Status.TaskSpec != nil && len(tr.Status.TaskSpec.Results) >= 1

chuangw6 · 2023-07-04T17:38:16Z

Hey @jagathprakash ,
Are there any updates on this PR? Or are there any blockers to move this forward?

afrittoli · 2023-07-13T11:00:04Z

docs/spire.md

@@ -6,13 +6,58 @@ weight: 1660
 -->
 ⚠️ This is a work in progress: SPIRE support is not yet functional


Is this still the case after this PR?

jerop · 2023-09-20T16:17:26Z

/close

@chuangw6 and I are hoping to pick this up soon

thank you @jagathprakash

tekton-robot · 2023-09-20T16:17:29Z

@jerop: Closed this PR.

In response to this:

/close

@chuangw6 and I are hoping to pick this up soon

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 added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note-none Denotes a PR that doesnt merit a release note. labels Jun 6, 2023

tekton-robot requested review from dibyom and pritidesai June 6, 2023 23:05

tekton-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jun 6, 2023

tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Jun 6, 2023

tekton-robot assigned chuangw6 and jerop Jun 6, 2023

jagathprakash mentioned this pull request May 22, 2023

[TEP-0089] Enforce non-falsifiable provenance using SPIRE #6597

Open

10 tasks

tekton-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-none Denotes a PR that doesnt merit a release note. labels Jun 13, 2023

jagathprakash marked this pull request as ready for review June 13, 2023 15:32

tekton-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 13, 2023

tekton-robot requested review from abayer and wlynch June 13, 2023 15:32

jagathprakash force-pushed the spire-tr branch from 8c223ab to df6700e Compare June 13, 2023 16:53

chitrangpatel reviewed Jun 13, 2023

View reviewed changes

wlynch requested changes Jun 14, 2023

View reviewed changes

jagathprakash requested a review from chitrangpatel June 14, 2023 14:27

tekton-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 17, 2023

jagathprakash force-pushed the spire-tr branch from df6700e to 3478bc3 Compare June 19, 2023 15:10

tekton-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 19, 2023

jagathprakash force-pushed the spire-tr branch from 3478bc3 to 2be2012 Compare June 19, 2023 16:15

jagathprakash force-pushed the spire-tr branch from 2be2012 to f5e8cd5 Compare June 19, 2023 16:35

jagathprakash force-pushed the spire-tr branch from f5e8cd5 to 02a4080 Compare June 19, 2023 18:37

jagathprakash force-pushed the spire-tr branch from 02a4080 to 48ce881 Compare June 19, 2023 19:07

chuangw6 reviewed Jun 26, 2023

View reviewed changes

afrittoli reviewed Jul 13, 2023

View reviewed changes

tekton-robot closed this Sep 20, 2023

	As the TaskRun progresses, the Pipeline Controller will reconcile the TaskRun object and continually verify the current hash against the `tekton.dev/status-hash-sig` before updating the hash to match the new status and creating a new signature.
	As the TaskRun progresses, the Pipeline Controller will reconcile the TaskRun object and continually verify the current hash against the signature in the annotation `tekton.dev/status-hash-sig` before updating the hash to match the new status and creating a new signature.

		if tr.IsSuccessful() && spireAPI != nil &&
		((tr.Status.TaskSpec != nil && len(tr.Status.TaskSpec.Results) >= 1) \|\| len(filteredResults) >= 1) {

		@@ -6,13 +6,58 @@ weight: 1660
		-->
		⚠️ This is a work in progress: SPIRE support is not yet functional

[TEP-0089] Enable the signing and verification of TR results and the TR status #6782

[TEP-0089] Enable the signing and verification of TR results and the TR status #6782

Conversation

jagathprakash commented Jun 6, 2023 • edited Loading

Changes

Submitter Checklist

Release Notes

tekton-robot commented Jun 6, 2023

jagathprakash commented Jun 6, 2023

jagathprakash commented Jun 6, 2023

tekton-robot commented Jun 6, 2023

chuangw6 commented Jun 12, 2023

jagathprakash commented Jun 12, 2023

tekton-robot commented Jun 13, 2023

tekton-robot commented Jun 13, 2023

tekton-robot commented Jun 13, 2023

tekton-robot commented Jun 13, 2023

tekton-robot commented Jun 13, 2023

tekton-robot commented Jun 13, 2023

chitrangpatel Jun 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chuangw6 commented Jun 13, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wlynch Jun 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tekton-robot commented Jun 19, 2023

tekton-robot commented Jun 19, 2023

tekton-robot commented Jun 19, 2023

tekton-robot commented Jun 19, 2023

tekton-robot commented Jun 19, 2023

tekton-robot commented Jun 19, 2023

tekton-robot commented Jun 19, 2023

tekton-robot commented Jun 19, 2023

tekton-robot commented Jun 19, 2023

tekton-robot commented Jun 19, 2023 • edited Loading

tekton-robot commented Jun 19, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chuangw6 commented Jul 4, 2023

Choose a reason for hiding this comment

jerop commented Sep 20, 2023 • edited Loading

tekton-robot commented Sep 20, 2023

jagathprakash commented Jun 6, 2023 •

edited

Loading

chitrangpatel Jun 13, 2023 •

edited

Loading

wlynch Jun 14, 2023 •

edited

Loading

tekton-robot commented Jun 19, 2023 •

edited

Loading

jerop commented Sep 20, 2023 •

edited

Loading