-
Notifications
You must be signed in to change notification settings - Fork 473
Fix PSS restricted warnings #2528
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
Fix PSS restricted warnings #2528
Conversation
Signed-off-by: Harshvir Potpose <hpotpose62@gmail.com>
7e4b506
to
305fc36
Compare
/ok-to-test |
/ok-to-test |
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.
This seems to relate to istio-ingressgateway. I would vote to add these parameters only to kubeflow integration
https://github.com/kubeflow/katib/tree/master/manifests/v1beta1/installs/katib-with-kubeflow
/hold |
Actually this is best practices for all Kubernetes pods and basic container security stuff https://kubernetes.io/docs/concepts/security/pod-security-standards/ So you should also have this as standalone application and i do not see how this is related to istio. |
I do not think so. PSS is not enforced by default. |
"PSS is not enforced by default" this is a severe security flaw. Pods should not be able to exploit the whole cluster by default and take over the infrastructure. Whether as standalone or Kubeflow platform installation. |
@tenzen-y Do you have a specific use-case when PSS should not be enforced by default ? |
@juliusvonkohout @akagami-harsh Is it a blocker for Katib 0.18 and Kubeflow 1.10 release, or we can post-pone it ? |
@andreyvelich I am also fine if you merge it after the Katib release this week, but in the next weeks for Kubeflow 1.10.1 we need it, since also most other working groups have this implemented or are close to it (Manifests, KFP, Modelregistry, Spark, ...) @tenzen-y. @akagami-harsh can you run this locally and check whether the MySQL really needs no fsgroup as KFP does for its database? I am not sure whether this is covered by the tests here. https://github.com/kubeflow/pipelines/blob/d1b15ef4da33cbeafa491564318c7e2a68dc431f/manifests/kustomize/third-party/mysql/base/mysql-deployment.yaml#L74-L75 is the pod-level fsgroup and fsGroupChangePolicy securitycontext for GCP. Otherwise this should be good to merge if the tests are green. |
Yes you are right Mysql need fsgroup, I tested it on my local machine and it wasn't working,
|
It works in kubeflow/manifests#3050 and the tests here are green as well so @andreyvelich @tenzen-y for approval |
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! @akagami-harsh
/lgtm
/assign @andreyvelich @tenzen-y
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 think, we can move this forward, but I let @tenzen-y for the final approval.
/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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andreyvelich 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 |
@akagami-harsh @juliusvonkohout Feel free to unhold. |
/unhold congratulations @akagami-harsh |
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):related to kubeflow/manifests#3050
Checklist: