-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store and validate TaskRun/Run UIDs in pipeline task embedded status #7833
base: main
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
See GHSA-w2h3-vvvq-3m53 This will ensure that scenarios like described in the linked advisory cannot occur - we'll read the `TaskRun`/`Run` UID when we initially add it to the embedded status, and if we ever encounter a `TaskRun`/`Run` with the same name but a different UID in the future, we'll throw an error. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
ed952dc
to
e563822
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @vdemeester for looking into this.
If someone can create a TaskRun
in the cluster, they are likely able to edit the PipelineRun
status as well and inject the TaskRun
there.
This helps but we will have to let the Tekton controller sign *Run
resources everytime there is an update to ensure that there was no tampering. If I'm not mistaken, we have the Spiffe/Spire integration almost finished to provide that capabilities.
Yes, but it's not going to be enabled by default. |
@vdemeester: 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. |
@@ -111,7 +112,7 @@ var ( | |||
ReasonFailedValidation = v1.PipelineRunReasonFailedValidation.String() | |||
// ReasonInvalidGraph indicates that the reason for the failure status is that the | |||
// associated Pipeline is an invalid graph (a.k.a wrong order, cycle, …) | |||
ReasonInvalidGraph = v1.PipelineRunReasonInvalidGraph.String() | |||
RewasonInvalidGraph = v1.PipelineRunReasonInvalidGraph.String() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
random drive by nit: typo 😜 ❤️
Changes
See GHSA-w2h3-vvvq-3m53
This will ensure that scenarios like described in the linked advisory
cannot occur - we'll read the
TaskRun
/Run
UID when we initiallyadd it to the embedded status, and if we ever encounter a
TaskRun
/Run
with the same name but a different UID in the future,we'll throw an error.
Signed-off-by: Vincent Demeester vdemeest@redhat.com
/cc @abayer @wlynch @tektoncd/core-maintainers
/kind bug
/area security
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes