-
Notifications
You must be signed in to change notification settings - Fork 179
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
Run components as non-root #141
Comments
That seems like something we should totally do indeed. Which specific user we choose, I'm not too concerned about. |
I'm wondering if we should choose a UID in the main project first, and set it the How breaking is the change? User might have to change the ownership of the volumes data, right? Store and Compactor data can be discarded, what about rule and receive? |
Receive might be the actual tricky one - yes. Ruler too. If we make it clear it should be fine to change. |
Actually the kubelet chowns the entire volume recursively before mounting to the fsgroup specified in the pod, so this should not break anything (unless the respective CSI driver is broken and doesn't do this, which we have seen with NFS sometimes but I don't think we should limit ourselves by incorrect implementations of CSI). |
Thanos components run as root by default:
Pods should probably have a restricted security context, I currently run them with the following (except receive and rule that I do not have):
Do you have an opinion on the uid/gid to use?
65534
/nobody
/nogroup
seems popular too, but not everyone thinks this what they should be used for.The text was updated successfully, but these errors were encountered: