-
Notifications
You must be signed in to change notification settings - Fork 28
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
Usage of the fsGroup securityContext #8
Comments
Hi @spawnia. Apologies for the late response. It's been a crazy month, and I haven't had time to calm down and take a look at some personal projects. This is a great suggestion, and hopefully I'll be able to get around and push a new version soon. Hang in there. |
Ok, so I'm taking a closer look at your idea... but I'm a little confused. The volume driver does not create the PV itself. It only mounts the volume with opts that were provided. In that regards, it seems to be working. Unfortunately, I'm not able to control how the PV is provisioned. Either manually or through a provisioner, the volume driver is unable to interact at that moment. Does that sound right? |
It seems as though Kubernetes does not allow controlling the permissions within certain kinds of provisioned volumes. I experimented a bit and found that Other people had similar issues with NFS: kubernetes/examples#260 |
I dug a little deeper - looks like Kubernetes will pass through the |
I did some testing with minikube using all values in the pod's securityContext:
runAsUser: 33
runAsGroup: 33
fsGroup: 33 and voilà, the following comes up as argument to the volume driver. {
"kubernetes.io/fsType": "",
"kubernetes.io/mounterArgs.FsGroup": "33",
"kubernetes.io/pod.name": "nginx-deployment-549ddfb5fc-rnqk8",
"kubernetes.io/pod.namespace": "default",
"kubernetes.io/pod.uid": "bb6b2e46-c80d-4c86-920c-8e08736fa211",
"kubernetes.io/pvOrVolumeName": "test-volume",
"kubernetes.io/readwrite": "rw",
"kubernetes.io/serviceAccount.name": "default",
"opts": "domain=Foo",
"server": "fooserver123",
"share": "/test"
} Except, Let me know what you think. |
I also prepared a 0.5-beta version you can test. Let me know if that works.
|
That's really awesome, thanks for digging in. I would like to review the code as well, could you put it up as a PR? |
There ya go |
Preface: Thanks for the plugin, it has been working great for us!
I am trying to mount a volume created through this driver into a container with a specific
uid
/gid
. Here is an abbreviated example of the configuration i am using:The volume is successfully mounted, but not as the specified Group
33
- it still belongs toroot:root
.I have to change the volume definition like so to make it work:
Now,
/var/www/test
is owned by33:33
.I would prefer to use
fsGroup
, as that would enable me to share the volume across multiple containers and change the user/group for each. Can that be achieved?This is more of a question, i am not sure if there is actually something you can do here. Happy about any advice.
The text was updated successfully, but these errors were encountered: