-
Notifications
You must be signed in to change notification settings - Fork 778
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
Statically provisioned PV/PVC don't set group ownership when fsGroup is defined #1365
Comments
Kubelet is responsible for managing |
@jbehrends were you able to confirm any behavior here? I am seeing the same thing, specifically with just using a raw |
@joshbranham @jbehrends did some further digging on this, and I don't think it's a kubelet bug but rather intentional feature. The kubelet refuses to use the
I tested with the static provisioning example by setting |
I can confirm setting |
Sorry, hadn't gotten a chance to test this till now. Also verified that setting "spec.csi.fsType" to ext4 fixes the issue. |
Opened a PR to update the static-provisioning example as @ConnorJC3 had suggested. |
It's certainly current behavior, but is it intentional? The volume is mounted at the point where It seems weird/wrong to force the user to specify an otherwise-optional parameter when the information is right at hand. |
EBS driver deployments could also default to |
@wmesard my understanding is that the @gnufied good catch, opening a PR for that. |
Closing this now since #1377 has been merged. |
/kind bug
What happened?
When following the "static-provisioning" example/method of using the aws-ebs-csi-driver, setting securityContext.fsGroup in your pod or deployment does NOT configure group ownership of the EBS volume mount. Setting fsGroup when using the "dynamic-provisioning" example DOES set the group ownership of the EBS volume correctly. This is an issue because our deployments use non-root uid/gid's and as a result the process running in the container can't write to the EBS volume mount because it's owned by root:root.
What you expected to happen?
Setting "securityContext.fsGroup" to a specific GID value should result in the volume mount and the files contained in the mount having the same GID applied to them.
How to reproduce it (as minimally and precisely as possible)?
The resulting pod will have a volume mount with ownership of root:root and it SHOULD be root:1000
Anything else we need to know?:
Environment
kubectl version
): EKS 1.21The text was updated successfully, but these errors were encountered: