-
Notifications
You must be signed in to change notification settings - Fork 420
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
Add flag to disable security context on EL Deployment #865
Add flag to disable security context on EL Deployment #865
Conversation
Hi @MarcelMue. Thanks for your PR. I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
@@ -61,12 +61,15 @@ const ( | |||
) | |||
|
|||
var ( | |||
// The container that we use to run in the EventListener Pods | |||
elImage = flag.String("el-image", "override-with-el:latest", | |||
// ELImage defines the container that we use to run in the EventListener Pods |
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.
I renamed this flag to capitalize it like the other flags. Mainly for consistency.
"The container image for the EventListener Pod.") | ||
// ElPort defines the port for the EventListener to listen on | ||
ElPort = flag.Int("el-port", 8080, | ||
"The container port for the EventListener to listen on.") | ||
// ELSetSecurityContext defines if the security context is set. | ||
ELSetSecurityContext = flag.Bool("el-security-context", true, |
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.
I would like to unit test this but have no idea how. Are there any examples where it's easy to tell how flags can be invoked for unit tests in this project?
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.
Current idea for me is to re-factor the flag setup in this controller to allow unit testing different values.
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.
One way might be to refactor one of the functions e.g. reconcileDeployment (or getDeployment) to take in a parameter called isSecurityContexEnabled
and then we write unit tests for those functions (we lack those smaller unit tests today but maybe we should add them)
Another way might be to add these as fields in the Reconciler struct and we can set the right values in the test Reconcilers.
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.
Another way might be to add these as fields in the Reconciler struct and we can set the right values in the test Reconcilers.
This is what I want to go for currently. I would like to do this as a follow up to this PR to prevent this from getting too big.
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.
sounds good to me!
/ok-to-test |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
"The container image for the EventListener Pod.") | ||
// ElPort defines the port for the EventListener to listen on | ||
ElPort = flag.Int("el-port", 8080, | ||
"The container port for the EventListener to listen on.") | ||
// ELSetSecurityContext defines if the security context is set. | ||
ELSetSecurityContext = flag.Bool("el-security-context", true, |
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.
Forgot to mention this during WG call
I think If we keep default value as true then for openshift
platform we need to update the controller deployment to set the flag to false
I believe which is extra step
so considering this shall we make default as false
@dibyom @bigkevmcd @gabemontero WDYT?
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.
Yeah, my understanding is that openshift already generates/modifies some of the YAML so it should be able to change/add the flag here: https://github.com/tektoncd/triggers/blob/master/config/controller.yaml#L62
Would that work?
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.
Yeah @savitaashture I think upstream needs to default to being able to function securely out of the box, which means being able to function if PSP is set to more restrictive default policies like what @MarcelMue and Jose experienced.
Which means default to true, no?
And then if openshift has to tweak more yaml like we do already when dealing with SCC vs. PSP, that that is what we have to do.
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.
Yes 👍
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.
Agreed, default to true is ok for me 👍🏼
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.
We will need to modify release.yaml for openshift because controller and webhook also have hardcoded UUID. So we can do for this flag also. We already do this for pipelines controller and webhook.
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.
The only downside of the flag approach (compared to a configmap approach) is that a user that wants to run upstream
triggers on OpenShift needs to edit the deployment, where, otherwise only a configmap edition is required (which is.. simpler..). But I am definitely fine with the flag 😉
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.
yeah in general, the number of flags are increasing...so it'd be nice to move to a configMap at some point.
76d5460
to
1033d70
Compare
I think this should be ready to merge now. Unit tests currently don't exist and will be added in a follow up. I can not find any place where we document these flags - correct me if I am wrong. |
The following is the coverage report on the affected files.
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dibyom 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 |
Changes
This is a follow up to #864 - it introduces a flag which removes the security context from all created deployments. This enables
triggers
to work correctly on OpenShift.Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Release Notes