-
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
PodSecurityPolicy Config fixes to allow runnning in restricted envs. #2967
Conversation
|
/kind bug |
/cc @gabemontero |
@skaegi I think this needs a |
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 to release noting
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 this one could probably use a release note. I can't think if a good way to word it, but in case people see weird permission issues pop up it would be good to have a release note to help them track it back to this change.
The build error should be fixed now /test pull-tekton-pipeline-build-tests |
Fixes #2966 1. Moves PSP rule from tekton-pipelines-controller-cluster-access ClusterRole to tekton-pipelines-controller Role. This reduces the scope of where the PSP can be used to prevent privilege escalation 2. Adds PSP rule to tekton-pipelines-webhook to allow the webhook to run when only restrice PSPs are provided 3. Update controller and webhook deployments to use... `runAsUser: 1001` instead of `runAsNonRoot: false` 4. Update tekton-pipelines PSP to use `runAsUser -- rule: 'MustRunAsNonRoot'` to further restrict the controller PSP 5. Added `allowPrivilegeEscalation: false` to the deployment template securityContext for tekton-pipelines-controller to match tekton-pipelines-webhook
updated release notes and squashed for enhanced beauty |
/hold cancel |
per the ask in AP WG today @skaegi I took another look ... more questions came up than anything else a) first the easy one ... so far all the changes so far look fine to me, and the needs for them that you cited seem valid to me If the answer to b) is "yes" and c) is "no", I might have some additional suggestions, but at first blush I'm hesitant to go down that path. But if that was your intent when you asked me to look, let me know and we can discuss. |
/approve This looks good to me! Thanks! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dlorenc 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 |
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.
/lgtm
Fixes #2966
Changes
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.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes