-
Notifications
You must be signed in to change notification settings - Fork 220
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
[TEP-0146] Parameters
in Script
#1077
[TEP-0146] Parameters
in Script
#1077
Conversation
/kind tep |
/assign |
/assign @Yongxuanzhang @JeromeJu |
@JeromeJu: GitHub didn't allow me to assign the following users: Yongxuanzhang. Note that only tektoncd members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. In response to this:
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. |
d251cb4
to
343cc97
Compare
Parameters
in Script
Parameters
in Script
Parameters
in Script
Parameters
in Script
Parameters
in Script
Parameters
in Script
5df79b0
to
7c0fe0d
Compare
/assign |
7c0fe0d
to
4e52c2a
Compare
Hi @aaron-prindle, thanks for the PR! We have a TEP template to leverage in case you don't know 😁 |
7467470
to
a34051a
Compare
spec.steps[0].script: $(params.url) cannot be injected into a script, consider moving | ||
into an environment variable on the Step. | ||
``` |
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.
If we did fail validation, we would then basically not support them at all, which would be a backwards incompatible change. We could do that in v2
, for v1
we might do that as an opt-in feature or a warning system - even though validation in itself does not have any facility for deprecations or warnings that I'm aware of, so it's unclear how the warning could be delivered to the user
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.
+1, currently the idea for rolling this out would be to keep backwards compatibility with an opt-in feature-gate for cluster operators to remove this in v1 (if we agree this makes sense). For the warnings, it wasn’t clear to me the de-facto way to do this in Tekton. As stated, we could output some “WARN: Tekton is deprecating <...>”, see docs link here for more information on deprecation timelines how to migrate <doc-link AND/OR link to TBD bespoke tkn
command for migration>” on creation of a Task but not sure how visible this might be to most end users.
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 for this proposal.
I left a couple of comments.
NIT: I have the impression that there was a proposal with the .env
syntax initially documented, and then removed in favour of a list of alternatives, as some part of the document seem to assume a specific design and others don't.
In any case, I'm happy to have this merged as a proposal, but I'd like to see more coverage of array/object params as well as non-bash environments (e.g. python).
7496e35
to
58dea96
Compare
5a72ddb
to
51c9714
Compare
Thank you for your feedback @afrittoli & @vdemeester! I’ve updated the document addressing all of the feedback posted (see individual comments). Wanted to address the points in you final comment below:
|
Thanks for the reviews here! @afrittoli - does this look good now to be merged as “proposed”? If not, what are the open questions to resolve to get this to implementable? I've added additional information and examples around array params, obj params, and non-bash environments. Happy to answer any additional q's or iterate on the doc as needed. Thanks! |
51c9714
to
e8a4754
Compare
e8a4754
to
218ae32
Compare
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.
What's the suggested solution here ? Usage of $(params.url.env)
or having ${PARAMS_URL}
working by default ? I am not sure I understand the before/after/resolved.
- Are we mutating the
Task
definition (to add the environment variables), or are we just setting them at Pod creation time ? - What happens if
params.url
andparams.URL
exists ? (I think we error out on those already, but I am not 100% sure 😅 ).
Hi @vdemeester, responding to your questions below:
|
Sounds good, thanks @aaron-prindle |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli, JeromeJu, vdemeester 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:
Approvers can indicate their approval by writing |
Thanks @vdemeester! Lmk if there is anything I need to do on my end to get this merged as |
We need someone who has the permission to lgtm |
This tep is very similar like https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable ? Is it mentioned in the proposal as a reference? |
This PR adds the problem statement for the TEP and identifies possible solutions. The proposal will be added in a subsequent PR after discussions of alternatives. Using `Parameter` variables directly in `script` blocks in `Tasks` is a footgun in two ways: - **Security**: It is easy for a `Task` _author_ to accidentally introduce a vector for code injection and, by contrast, difficult for a `Task` _user_ to verify that such an injection can't or hasn't taken place. - **Reliability**: It is easy for a `Task` _user_ to accidentally pass in a `Parameter` with a character that would make the `Script` invalid and fail the `Task`, making the `Task` extremely fragile. To solve the above problems, this TEP aims to: - Introduce a safe and reliable way to access `Parameter` variables from `Scripts`, and update the documentation and *Tekton Catalog* with the new approach. - Disallow use of `Parameter` variables directly in `script` blocks of `Steps` in *Tekton Pipelines V1 API*. References: * Issues: * tektoncd/pipeline#3226 * tektoncd/triggers#675 * tektoncd/plumbing#971 * [Catalog Guidance to Avoid Using `Parameters` in `Script` Blocks](https://github.com/tektoncd/catalog/blob/main/recommendations.md#dont-use-interpolation-in-scripts-or-string-arguments) * Tekton Enhancement Proposals: * [TEP-0017: Shell-Escaped Parameters](#208) * [TEP-0023: Implicit Parameters](https://github.com/tektoncd/community/blob/main/teps/0023-implicit-mapping.md) * [TEP-0099: Parameters in Script](#596) Co-authored-by: Jerop Kipruto <[email protected]> Co-authored-by: Scott Seaward <[email protected]>
218ae32
to
8fc98b8
Compare
@Yongxuanzhang - just added this as a reference, thanks! |
/lgtm |
This PR adds the problem statement for the TEP and identifies possible solutions. The proposal will be added in a subsequent PR after discussions of alternatives.
Using
Parameter
variables directly inscript
blocks inTasks
is a footgun in two ways:Task
author to accidentally introduce a vector for code injection and, by contrast, difficult for aTask
user to verify that such an injection can't or hasn't taken place.Task
user to accidentally pass in aParameter
with a character that would make theScript
invalid and fail theTask
, making theTask
extremely fragile.To solve the above problems, this TEP aims to:
Parameter
variables fromScripts
, and update the documentation and Tekton Catalog with the new approach.Parameter
variables directly inscript
blocks ofSteps
in Tekton Pipelines V1 API.References:
script:
pipeline#3226 * Escape incoming data triggers#675 * UseEnvironment Variables
instead ofParameters
inScript
plumbing#971Parameters
inScript
Blocks