-
Notifications
You must be signed in to change notification settings - Fork 715
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
Support non-root control-plane services #1367
Comments
I would love to work on this as my first contrib to |
Thanks @vjdhama |
@vjdhama are you working on this issue. I was thinking of giving it a try ? cc @yagonobre |
@ashishranjan738 Yes, I am. |
We're picking this up, but would like some clarification. What user/group should the processes run as instead of root? Is there an existing user/group that can be assumed to exist and be unprivileged or should this be a new configuration option? |
everybody was at kubecon, so might have been better to not send the PR before that. |
On our PR that made UID/GID configurable, @rosti said:
In this case, what UID/GID should the processes be run as by default? |
This will be needed to complete the work kubernetes/kubernetes#79722 |
the usage of here is a dump of the kubeadm static pods.
|
deadlines for KEPs is done. if someone has the bandwidth deadline for KEP exceptions is 19 Aug. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/lifecycle frozen |
moved to #1367 |
Seems this is a self-referential link @neolit123 ? 🤔 Was there a different issue this should've been linked to? |
my mistake, it's here: |
No worries. And thanks! 😃 |
Currently (kubeadm 1.13), the services deployed using static manifests on the control-plane node(s) are running as the
root
user, even though this is not strictly required, as long as FS permissions on whatever ishostPath
-exported in the Pods are set up correctly.Using
securityContext.runAsUser
andfsGroup
one can set the UID and GID under which the process in the container should run. It would be useful, from a security PoV, to drop to an unprivileged user (based on configuration, if need be) when executingetcd
,kube-apiserver
,kube-controller-manager
andkube-scheduler
.We could even consider dropping all 'capabilities' except those required to retain (if any).
edit by neolit123
k/e tracking issue:
kubernetes/enhancements#2568
The text was updated successfully, but these errors were encountered: