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
cleanup: remove extra permission in templates #2518
Conversation
21f1d23
to
4333eb0
Compare
4333eb0
to
4ab3004
Compare
/retest all |
4ab3004
to
e1c4db9
Compare
privileged: true | ||
capabilities: | ||
add: ["SYS_ADMIN"] | ||
allowPrivilegeEscalation: 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.
@Madhu-1 just wanted to mention one thing here, eventhough we mention kube as a known to work CO, I am wondering does this have any effect on OCP . Because the previlege
and caps
are treated with bit different way in OCP. so if at all we can do a quick test of this PR against OCP that would be good. I dont have solid confirmation that, this will break or work , so sharing my thought .
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.
as this is a provisioner pod we don't need this to be privileged?
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 have tested this with OCP 4.8 everything was working fine when the provisioner pod is not privileged.
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.
Cool, if you have tested it against one of the OCP versions, we are good . 👍
e1c4db9
to
83f4a68
Compare
- "secret" | ||
- "downwardAPI" | ||
- "projected" |
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.
@Madhu-1 is it failing without projected
?
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.
Tested with multiple kubernetes versions, Yes it's failing without projected and secrets
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.
hmmm :(, I dont see a reason to have a projected
volumes here, however if its failing without that , lets live with it .. thanks for the clarification.
Mostly looks good, just waiting for a confirmation on projected volume conf in snapshot PSP. 👍 |
/retest all
Yes without project and secret most of the deployment fails in different kubernetes versions #2518 (comment) |
83f4a68
to
02013af
Compare
/retest ci/centos/upgrade-tests-rbd |
/retest ci/centos/mini-e2e-helm/k8s-1.22 |
/retest ci/centos/mini-e2e/k8s-1.20 |
|
we dont need securityContext for the cephfs provisioner pod as its not doing any special operations like mounts, selinux etc. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
we dont need securityContext for the cephfs provisioner pod as its not doing any special operations. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
we dont need securityContext for the rbd provisioner pod as its not doing any special operations like map ,unmap selinux etc. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
rbd deployment doesnot need extra permission like privileged,Capabilities and remove unwanted volumes. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
removed extra volume permissions from the rbd nodeplugin PSP. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
cephfs deployment doesnot need extra permission like privileged,Capabilities and remove unwanted volumes. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
removed extra volume permissions from the cephfs nodeplugin PSP. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
cephfs deployment doesnot need extra permission like privileged,Capabilities and reduce unwanted volumes. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
removed extra volume permissions from the cephfs nodeplugin PSP. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
rbd deployment doesnot need extra permission like privileged and extra volumes etc. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
removed extra volume permissions from the rbd nodeplugin PSP Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
we dont need securityContext for the cephfs provisioner pod as its not doing any special operations like mount, selinux operations etc . Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
removed extra PSP permissions added for the snapshot controller deployment Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
02013af
to
c904c64
Compare
This PR removes all the extra permissions provided for CephFS, RBD, and snapshot templates and also it removes extra PSP permission and helps us to keep the minimal permission required for cephcsi to work.
Signed-off-by: Madhu Rajanna madhupr007@gmail.com