[TEP-0091]Trusted Resources #739

Yongxuanzhang · 2022-06-24T20:33:40Z

This commit proposes one solution to veriy the Tekton Resources via
admission webhook. It aims at starting the discussion on this work and
drives the Trusted Resources launched to Alpha.

This is a fork of #537 and work from @wlynch, and adapt it based on the poc in https://github.com/tektoncd/experimental/tree/main/pipeline/trusted-resources

Yongxuanzhang · 2022-06-24T20:53:54Z

@wlynch @dibyom Looking forward to your comments!

jerop

/kind tep

dibyom · 2022-06-27T16:09:48Z

/assign @wlynch
/assign @dibyom

dibyom · 2022-06-27T16:10:13Z

/assign @afrittoli

ywluogg · 2022-06-30T20:14:49Z

@ywluogg

wlynch

Looks good! Just a few minor comments.

wlynch · 2022-07-05T14:03:19Z

teps/0091-trusted-resources.md

+
+### Verify the Resources
+
+A new validating webhook should be implemented to do the verification. To receive the admission request new types should be implemented to include the Tekton TaskRun and PipelineRun as field, future Tekton Resources can also be extended this way.


fwiw, if we're adding this to Pipelines I wouldn't be opposed to adding this to the existing validation webhook. The separate webhook we were using in experimental was primarily to allow optional installation.

(that said, also fine to ship the second webhook to start if that simplifies things)

Oh ok. So should I include both options?

Add into existing webhook

Add a new webhook

yeah packaging the new webhook into the pipeline webhook binary should be straightforward.

I changed this section to add the verification into current admission webhook, and it should be gated by a new configmap.

wlynch · 2022-07-05T14:04:57Z

teps/0091-trusted-resources.md

+}
+```
+
+The new types should implement `Validate()` and verify the Resources.


We should be careful not to expose new types to the users if we can avoid it - we should try to unexport these / put into an internal package if possible for the real impl.

you mean add all the stuff into existing tekton pipeline?

if we integrate into the pipeline then this shouldn't be a problem. I have changed the tep to propose to add to the pipeline

wlynch · 2022-07-05T14:06:22Z

teps/0091-trusted-resources.md

+
+Validating webhook can use configmap to allow users to config when the Resource fails the verification
+1) Directly fail the run;
+2) Not fail the run but annotate the run with `tekton.dev/pass-verification: false`;


We should be careful not to place too much trust into this option, since it can be mutated later by another user later on.

If possible, could this be added to the status so that the data can be signed by SPIFFE/SPIRE?

We should be careful not to place too much trust into this option, since it can be mutated later by another user later on.

Oh yes, so for status did you mean this?https://github.com/tektoncd/pipeline/blob/6876520132f3bb22ff076e6a223b7114e936c611/pkg/apis/pipeline/v1beta1/taskrun_types.go#L120-L125

Updated the tep to propose adding a field under TaskRunStatus, and add the result into this new field

wlynch · 2022-07-05T14:08:47Z

teps/0091-trusted-resources.md

+1) Directly fail the run;
+2) Not fail the run but annotate the run with `tekton.dev/pass-verification: false`;
+If it passes the verification, the run will be annotated with `tekton.dev/pass-verification: true`
+


3rd option - you might also be interested in returning a warning response for failure for non-enforced validation. https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#response

is it something we can do within knative's admission webhook?

Not 100% sure but I think this might be possible by setting the DiagnosticLevel when retuning an apis.FieldError from the webhook validation

This is supported in knative 3 months ago. knative/pkg#2498
Just check the code pipeline is not updated to include this change but operator does.
I can update this in the tep

teps/0091-trusted-resources.md

pritidesai · 2022-07-11T16:08:07Z

API WG - @dibyom is still reviewing and can merge offline - proposed TEP with PoC in experimental repo.

teps/0091-trusted-resources.md

dibyom · 2022-07-11T16:04:48Z

teps/0091-trusted-resources.md

+
+### Performance (optional)
+
+For remote Resources such as OCI bundle, it will take time to fetch the resources. Resources that are not


Do you have a rough estimate of how long the resource fetch takes?

I don't have right now. It will depend on how revolver work and also what remote source we are fetching. For now I can make some experiment, like for the OCI case, if I pull it from docker hub, how long it will take. To get a rough estimate of it!

Tested a simple task oci bundle fetching from docker hub and the time is very short, can be ignored.

I'm still a bit worried about the remote artifact fetch particularly if this is done as a validation webhook and uses remote resolution - that would involve the webhook creating a ResolutionRequest CR, waiting for the Resolver to finish resolving, and making a validation decision.

(One mitigation would be to do this verification in the reconciler (or the resolver) instead of in the admission webhook)

Yes, and this also needs to give webhook the permission to fetch the tasks/pipelines. It's not so difficult to do it after resolution.

How would this work with a validation webhook and remote resources?
Would the validation webhook apply to the TaskRun / PipelineRun? That would mean that both the webhook and controller would have to fetch remote resources, unless the controller would have a way to use the resources fetched by webhook.

How would this work with a validation webhook and remote resources? Would the validation webhook apply to the TaskRun / PipelineRun? That would mean that both the webhook and controller would have to fetch remote resources, unless the controller would have a way to use the resources fetched by webhook.

Yes you're right that both the webhook and controller would have to fetch remote resources if this feature is enabled and we want to have the verification in webhook.

Another option is that we can integrate the verification together with remote resolution, either in the reconciler after resolving or in the resolver.

Something to balance when thinking about webhook vs reconcile validation - validation before admission is the safer strategy because the resource can be blocked before downstream informers are aware of them.

Other OCI based policy webhooks (OPA, Kyverno, sigstore/policy-controller) seem to do fine with network based lookups at admission time, though I get we also want to dedup fetching efforts between this and RemoteResolution.

If we go down the reconcile validation path, we should be careful about documenting when resources are considered trusted and how that information is exposed to users in the Run status (e.g. it might be worth having a dedicated termination status marking a Run as unverified?). Even then, there may still be some utility in a webhook based validation to make sure that the Run object itself hasn't been tampered with. 🤔

Agreed with the caveats around reconciler based validation but I do think there is (or will be) a difference in the remote fetch between this webhook and OPA/policy controller - with remote resolution for resource fetches, the webhook will have to create a custom resource and then watch for update to its status as opposed to a sync HTTP request/response

dibyom · 2022-07-11T16:11:17Z

teps/0091-trusted-resources.md

+  Some possible  mitigations include the following:
+
+  1. Update the Resources to add the missing mutating values (e.g. Use `SetDefaults`) everytime we bump the version of Tekton Pipeline.
+  2. Avoid mutating Tekton Resources or move the mutating after verification.


Wouldn't another mitigation be moving the verification from the webhook to the reconciler?

Correct me if I'm wrong.
If we move it to the reconciler, for local tasks/pipelines they still need to go through mutating webhook. And the content may be changed. The flow is:
mutating -> validation -> reconciler

I can do some research this week and see if there are better ways!

You are right. One option is that we apply the SetDefaults() each time on reconcile instead of at admission time (so the object stored in etcd is not mutated)

Another possibility might be having the CLI that is doing the signing make a dry-run call to the API server to get the resource defaults set and sign that https://kubernetes.io/docs/reference/using-api/api-concepts/#dry-run

Oh thanks!
The dryrun is really helpful, Billy just also mentioned this.
Right now it is similar that I add call setdefaults during signing, the benefit is that it will not depend a running cluster, but it cannot guarantee that the setdefault is the same as the cluster's tekton. So I think what you're suggesting is better!

+1 for moving defaults to the reconciler - the less we mutate the config before verification the better.

+1 for moving defaults to the reconciler - the less we mutate the config before verification the better.

I think people may not like this idea but I will keep this as an option. Because it is kind of against the original desgin of admission webhooks? That is all the request objects need to be mutated and then validate, and some validating logic assume that this object must be mutated.

We encountered some issues recently that resources not go through the mutating will fail in validating.
If we move mutating into reconciler then what stored in etcd is not mutated and fully validated.

If we can do verification->mutating->verification then it may be better?

dibyom · 2022-07-11T16:18:46Z

teps/0091-trusted-resources.md

+
+### Verify the Resources
+
+A new validating webhook should be implemented to do the verification. To receive the admission request new types should be implemented to include the Tekton TaskRun and PipelineRun as field, future Tekton Resources can also be extended this way.


yeah packaging the new webhook into the pipeline webhook binary should be straightforward.

dibyom · 2022-07-11T16:32:51Z

teps/0091-trusted-resources.md

+1) Directly fail the run;
+2) Not fail the run but annotate the run with `tekton.dev/pass-verification: false`;
+If it passes the verification, the run will be annotated with `tekton.dev/pass-verification: true`
+


Not 100% sure but I think this might be possible by setting the DiagnosticLevel when retuning an apis.FieldError from the webhook validation

dibyom · 2022-07-11T16:49:22Z

This sounds good to me @Yongxuanzhang -- have a couple of questions. I think once you squash the 2 commits, we can merge this.

Yongxuanzhang · 2022-07-28T20:01:18Z

Hi @wlynch @dibyom, I went through the comments of this tep,
So from your comment, we can add this into the current pipeline's webhook.
I have 2 questions regarding direction.

Do we need to worry about introducing more dependency into the pipeline? cosign and sigstore will be added into the go.mod, not sure if that is ok. But since SPIFFE/SPIRE also integrate into the pipeline, maybe that is fine?
We have the command line code for singing the yaml files. Where is the best place to put them? Under pipeline/cmd?

Yongxuanzhang · 2022-08-04T14:59:52Z

Hi @wlynch @dibyom, I went through the comments of this tep, So from your comment, we can add this into the current pipeline's webhook. I have 2 questions regarding direction.

Do we need to worry about introducing more dependency into the pipeline? cosign and sigstore will be added into the go.mod, not sure if that is ok. But since SPIFFE/SPIRE also integrate into the pipeline, maybe that is fine?

We have the command line code for singing the yaml files. Where is the best place to put them? Under pipeline/cmd?

The TEP is adjusted to add into Tektoncd/Pipeline
The signing can go to cmd, there is another tep before discussing adding sign/verify into tkn. This can be also considered

dibyom · 2022-08-05T00:34:47Z

Do we need to worry about introducing more dependency into the pipeline? cosign and sigstore will be added into the go.mod, not sure if that is ok. But since SPIFFE/SPIRE also integrate into the pipeline, maybe that is fine?

I think this is ok. If we really have to, it should be straightforward to split off into its own binary

We have the command line code for singing the yaml files. Where is the best place to put them? Under pipeline/cmd?

I think eventually this should make it into tkn

dibyom · 2022-08-05T00:35:43Z

teps/0091-trusted-resources.md

+There are several ways to integrate the Trusted Tesource with Remote Resource Resolution
+
+
+| Method | Pros | Cons |


Are you leaning towards one of these options at the moment?

Right now the implementation is based on callbacks in validation webhook of pipeline. I think the benefit of having it in webhook is that we can fail the run/build instantly when it fails the verification.

I discussed the integration with remote resolution in one of the working groups before, and Priti suggested me to wait until the remote resolution come to beta version.

dibyom

I think this good to merge as proposed though we should decide if it makes sense to support remote resources verification via a webhook or not.

/approve

afrittoli

Thanks for this.

I think there are still some details to be fleshed out, but it looks good for "proposed" status, this is definitely a capability we should have.

/approve

afrittoli · 2022-08-08T09:14:02Z

teps/0091-trusted-resources.md

+This proposal will introduce a new admission webhook to Tekton to verify a
+Tekton Resource and can indicate that the verification must occur.


Is this sentence still up to date? An admission controller might not work for remote resources?

Thanks!

Right now it is not necessarily a new admission webhhook, after some experiments last week we can just add some new callbacks into Pipelines's validating webhook to do the verification. I will update the tep.

Correct me if I'm wrong, Admission controller should be able to fetch remote resources just like what we do in reconciler, right now the implementation can fetch the oci bundles using k8schain?

afrittoli · 2022-08-08T09:16:44Z

teps/0091-trusted-resources.md

+the builder images. These builder images may have been compromised and the
+Task would still be considered verified.


What are "builder images"? Are these the images used in the steps? If so, I would recommend to stick to the standard Tekton nomenclature to avoid confusion, and define any new nomenclature that needs to be introduced.

Yes, it refers to the step images. So should I use step images?

afrittoli · 2022-08-08T09:20:13Z

teps/0091-trusted-resources.md

+
+**Author publishing a Resource.**
+A Resource Author may want their Resource and its
+outputs to be trusted so that provenance attestations can be confidently made. The author will use the private key to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).


I think it would be good to expand on "the" private key.
Where does this key come from, what role does an author need to have to have access to a private key and sign resources, do we trust all signed resources or can specify a set of trusted signing keys?

Thanks! This is a great point.
The current idea/assumption is that, the private keys should come from the users who want to use this feature. So it is quite flexible that some users can have their own private keys and publish the public keys. Tektoncd or pipeline doesn't provide private keys right now.

If this makes sense, I can expand this section to clarify. Of if you have any other suggestions pls let me know. 😄

possibly just a phrasing thing? the use of "the private" makes it sound like there's a preexisting key that users should use, when really IIUC this is just an arbitrary key pair under the users control?

Suggested change

outputs to be trusted so that provenance attestations can be confidently made. The author will use the private key to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).

outputs to be trusted so that provenance attestations can be confidently made. The author will use their own public/private key pair to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).

actually reading on below with the configmap, might need some more clarification

afrittoli · 2022-08-08T09:21:37Z

teps/0091-trusted-resources.md

+outputs to be trusted so that provenance attestations can be confidently made. The author will use the private key to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).
+
+**Verify the Resource via validating webhook.**
+The user will need to deploy the validating webhook to the cluster, by default the webhook will reject a Resource if it fails the verification. The webhook will mark if this Resource fails or passes the verification.


Will the deployment be on by default and enforcement controlled via configuration?
Any implication on the operator here?

Will the deployment be on by default and enforcement controlled via configuration?

This will be gated by alpha and a new configmap, and by default it should just skip the verification. This section is not updated and I will update right now!

afrittoli · 2022-08-08T09:25:06Z

teps/0091-trusted-resources.md

+
+### Performance (optional)
+
+For remote Resources such as OCI bundle, it will take time to fetch the resources. Resources that are not


How would this work with a validation webhook and remote resources?
Would the validation webhook apply to the TaskRun / PipelineRun? That would mean that both the webhook and controller would have to fetch remote resources, unless the controller would have a way to use the resources fetched by webhook.

afrittoli · 2022-08-08T09:29:33Z

teps/0091-trusted-resources.md

+The verification should be done in the Tekton Pipeline's admission webhook. A new configmap should be added to gate the verification
+code.


Not all Tekton resources are installed on the cluster, so the admission webhook will not catch remote resources and OCI bundles.

Yeah that's what we want to include in this verification process, we need to fetch these resources

afrittoli · 2022-08-08T09:32:32Z

teps/0091-trusted-resources.md

+
+| Method | Pros | Cons |
+| -------- | ----------- | ----------- |
+| Call Resolution in Webhook | Easy decoupled implementation, less dependency introduced to Pipeline | Duplicate work for Resolution


Which webhook does this refer to?

This is the current validating webhook. I just updated it.

tekton-robot · 2022-08-08T10:08:21Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afrittoli, dibyom, 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:

~~teps/OWNERS~~ [afrittoli,dibyom,wlynch]

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

wlynch · 2022-08-08T19:25:19Z

teps/0091-trusted-resources.md

+  Some possible  mitigations include the following:
+
+  1. Update the Resources to add the missing mutating values (e.g. Use `SetDefaults`) everytime we bump the version of Tekton Pipeline.
+  2. Avoid mutating Tekton Resources or move the mutating after verification.


+1 for moving defaults to the reconciler - the less we mutate the config before verification the better.

wlynch · 2022-08-08T19:29:16Z

teps/0091-trusted-resources.md

+
+**Author publishing a Resource.**
+A Resource Author may want their Resource and its
+outputs to be trusted so that provenance attestations can be confidently made. The author will use the private key to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).


possibly just a phrasing thing? the use of "the private" makes it sound like there's a preexisting key that users should use, when really IIUC this is just an arbitrary key pair under the users control?

Suggested change

outputs to be trusted so that provenance attestations can be confidently made. The author will use the private key to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).

outputs to be trusted so that provenance attestations can be confidently made. The author will use their own public/private key pair to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).

wlynch · 2022-08-08T19:33:02Z

teps/0091-trusted-resources.md

+
+`skip-verification`. (Optional, default `true`), if true then directly return nil, if false then do the verfication
+
+`cosign-pubkey-path`. (Optional, default `/etc/signing-secrets/cosign.pub`), it specifies the secret path to store the cosign pubkey


This will be difficult to support for multiple keys. You'll probably want a policy configuration similar to https://github.com/sigstore/policy-controller.

Just checked this repo. So ClusterImagePolicy is actually a new CRD created? Maybe to support multiple keys we can also have a new keyref type in tekton?

wlynch · 2022-08-08T20:01:03Z

teps/0091-trusted-resources.md

+
+### Performance (optional)
+
+For remote Resources such as OCI bundle, it will take time to fetch the resources. Resources that are not


Something to balance when thinking about webhook vs reconcile validation - validation before admission is the safer strategy because the resource can be blocked before downstream informers are aware of them.

Other OCI based policy webhooks (OPA, Kyverno, sigstore/policy-controller) seem to do fine with network based lookups at admission time, though I get we also want to dedup fetching efforts between this and RemoteResolution.

If we go down the reconcile validation path, we should be careful about documenting when resources are considered trusted and how that information is exposed to users in the Run status (e.g. it might be worth having a dedicated termination status marking a Run as unverified?). Even then, there may still be some utility in a webhook based validation to make sure that the Run object itself hasn't been tampered with. 🤔

Yongxuanzhang · 2022-08-09T19:54:56Z

@jagathprakash

Yongxuanzhang · 2022-08-10T20:22:09Z

Summarize some discussions here cuz it may be difficult to track new replies:
Where should we do the verification?

Validating webhook: Fail fast of the resources but will need to do dup work of resources resolution.
Reconciler: The tampered resources may be persistent in storage, but no dup work no extra cost.
Mutating Webhook and Validating webhook: Mutating Webhook first verify, and mark the taskrun as fail or pass, later validating webhook can check and reject it. (Optional: The mutating webhook can also resign the resources via the private keys, so if there are case for multiple mutating webhook, they can be verified again. )

I personally prefer to do the verification in admission webhooks, so that we can make sure the resources who are not trusted be kept out of the gate.

Yongxuanzhang · 2022-08-10T20:32:47Z

How to avoid the impact from mutating webhooks to the verification, this is only a concern for local resources, those who are applied in. cluster:

Mitigation methods: call setdefaults when signing the yaml files, every time we bump the pipeline version or change the mutating webhooks, users may need to resign the files again.
Move mutating webhook into reconciler: The flow will be Validating+Verification -> Reconcile (Mutating+Validation). There are some validation logic based on mutating webhook. So this means we need to decouple this dependency.
Do verification in mutating webhook before all the mutations.

dibyom · 2022-08-15T16:55:35Z

@Yongxuanzhang thanks for the summary. Very helpful. Do you want to add these open questions to the TEP and we merge this PR or should we keep discussing those options on this PR itself? (I think I have a preference for the first option)

This commit proposes one solution to veriy the Tekton Resources via admission webhook. It aims at starting the discussion on this work and drive the Trusted Resources launched to Alpha.

Yongxuanzhang · 2022-08-15T17:32:10Z

Where should we do the verification?

Validating webhook: Fail fast of the resources but will need to do dup work of resources resolution.

Reconciler: The tampered resources may be persistent in storage, but no dup work no extra cost.

Mutating Webhook and Validating webhook: Mutating Webhook first verify, and mark the taskrun as fail or pass, later validating webhook can check and reject it. (Optional: The mutating webhook can also resign the resources via the private keys, so if there are case for multiple mutating webhook, they can be verified again. )

Thank you! @dibyom 😄 I have included them and updated this PR. Maybe we can merge it first!

dibyom · 2022-08-15T18:02:24Z

/lgtm

tekton-robot requested review from piyush-garg and sthaha June 24, 2022 20:33

tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jun 24, 2022

jerop reviewed Jun 27, 2022

View reviewed changes

tekton-robot added the kind/tep Categorizes issue or PR as related to a TEP (or needs a TEP). label Jun 27, 2022

tekton-robot assigned dibyom and wlynch Jun 27, 2022

tekton-robot assigned afrittoli Jun 27, 2022

dibyom mentioned this pull request Jun 27, 2022

TEP-0091: Verified Remote Resources #537

Closed

tekton-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 5, 2022

wlynch approved these changes Jul 5, 2022

View reviewed changes

tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 5, 2022

Yongxuanzhang force-pushed the trusted-resources branch from ba89bda to 82f9a3f Compare July 6, 2022 18:58

tekton-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 6, 2022

This was referenced Jul 8, 2022

Discuss whether Chains should check artifact's digest in TaskRun tektoncd/chains#485

Closed

Add Intoto Signable Target support in Chains using strings in results. tektoncd/chains#465

Merged

dibyom reviewed Jul 11, 2022

View reviewed changes

Yongxuanzhang force-pushed the trusted-resources branch from 82f9a3f to 43c4355 Compare July 27, 2022 20:49

Yongxuanzhang requested review from dibyom and wlynch July 28, 2022 20:01

Yongxuanzhang force-pushed the trusted-resources branch 3 times, most recently from ebf2a79 to bb0f0b2 Compare August 3, 2022 20:28

Yongxuanzhang force-pushed the trusted-resources branch from bb0f0b2 to 8033cbd Compare August 4, 2022 21:23

dibyom reviewed Aug 5, 2022

View reviewed changes

afrittoli reviewed Aug 8, 2022

View reviewed changes

Yongxuanzhang force-pushed the trusted-resources branch from 8033cbd to 4160326 Compare August 8, 2022 19:26

Yongxuanzhang requested a review from afrittoli August 8, 2022 19:44

wlynch reviewed Aug 8, 2022

View reviewed changes

Yongxuanzhang mentioned this pull request Aug 9, 2022

[TEP-0093] tkn cli sign verify #545

Closed

Yongxuanzhang requested review from dibyom and wlynch August 11, 2022 16:27

Yongxuanzhang force-pushed the trusted-resources branch from 4160326 to 2fdd838 Compare August 15, 2022 15:26

[TEP-0091]Trusted Resources

08010fe

This commit proposes one solution to veriy the Tekton Resources via admission webhook. It aims at starting the discussion on this work and drive the Trusted Resources launched to Alpha.

Yongxuanzhang force-pushed the trusted-resources branch from 2fdd838 to 08010fe Compare August 15, 2022 17:31

tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Aug 15, 2022

tekton-robot merged commit a618e10 into tektoncd:main Aug 15, 2022


		### Verify the Resources

		A new validating webhook should be implemented to do the verification. To receive the admission request new types should be implemented to include the Tekton TaskRun and PipelineRun as field, future Tekton Resources can also be extended this way.


		### Performance (optional)

		For remote Resources such as OCI bundle, it will take time to fetch the resources. Resources that are not

		There are several ways to integrate the Trusted Tesource with Remote Resource Resolution


		\| Method \| Pros \| Cons \|

		This proposal will introduce a new admission webhook to Tekton to verify a
		Tekton Resource and can indicate that the verification must occur.

		the builder images. These builder images may have been compromised and the
		Task would still be considered verified.

	outputs to be trusted so that provenance attestations can be confidently made. The author will use the private key to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).
	outputs to be trusted so that provenance attestations can be confidently made. The author will use their own public/private key pair to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).

		The verification should be done in the Tekton Pipeline's admission webhook. A new configmap should be added to gate the verification
		code.


		`skip-verification`. (Optional, default `true`), if true then directly return nil, if false then do the verfication

		`cosign-pubkey-path`. (Optional, default `/etc/signing-secrets/cosign.pub`), it specifies the secret path to store the cosign pubkey

[TEP-0091]Trusted Resources #739

[TEP-0091]Trusted Resources #739

Conversation

Yongxuanzhang commented Jun 24, 2022 • edited Loading

Yongxuanzhang commented Jun 24, 2022

jerop left a comment

Choose a reason for hiding this comment

dibyom commented Jun 27, 2022

dibyom commented Jun 27, 2022

ywluogg commented Jun 30, 2022

wlynch left a 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

Yongxuanzhang Jul 27, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yongxuanzhang Jul 6, 2022 • 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pritidesai commented Jul 11, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dibyom Aug 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yongxuanzhang Aug 8, 2022 • 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yongxuanzhang Aug 9, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dibyom commented Jul 11, 2022

Yongxuanzhang commented Jul 28, 2022

Yongxuanzhang commented Aug 4, 2022

dibyom commented Aug 5, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dibyom left a comment

Choose a reason for hiding this comment

afrittoli left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yongxuanzhang Aug 8, 2022 • 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

Yongxuanzhang Aug 8, 2022 • 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

Yongxuanzhang Aug 8, 2022 • 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

Yongxuanzhang commented Jun 24, 2022 •

edited

Loading

Yongxuanzhang Jul 27, 2022 •

edited

Loading

Yongxuanzhang Jul 6, 2022 •

edited

Loading

dibyom Aug 5, 2022 •

edited

Loading

Yongxuanzhang Aug 8, 2022 •

edited

Loading

Yongxuanzhang Aug 9, 2022 •

edited

Loading

afrittoli left a comment •

edited

Loading

Yongxuanzhang Aug 8, 2022 •

edited

Loading

Yongxuanzhang Aug 8, 2022 •

edited

Loading

Yongxuanzhang Aug 8, 2022 •

edited

Loading

Yongxuanzhang commented Aug 10, 2022 •

edited

Loading