Mounting kubernetes volume with User permission

Question

I am using Kubernetes yaml to mount a volume. I know I can set the mount folder to be for a specific group using this configuration:

  securityContext:
    fsGroup: 999

but no where I can find a way to also set user ownership and not just the group.

When I access the container folder to check ownership, it is root.

Anyway to do so via kubernetes Yaml? I would expect fsUser: 999 for example, but there is no such thing. :/

score 6 · Accepted Answer · answered Mar 29 '21 at 17:04

There is no way to set the UID using the definition of Pod but you can use an initContainer with the same volumeMount as the main container to set the required permissions.

It is handy in cases like yours where user ownership needs to be set to a non root value.

Here is a sample configuration (change it as per your need):

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false
  initContainers:
  - name: volume-mount-hack
    image: busybox
    command: ["sh", "-c", "chown -R 999:999 /data/demo"]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo

it's a bit confusing though, the linux image which we are running initContainers is different, so the permission of the mounted folder is relevant to this specific linux. how come when I run my app container, it still knows about the permissions which I set on the other linux image? — toto, Mar 29 '21 at 18:03

score 2 · Answer 2 · answered Mar 29 '21 at 16:48

No, there is no such option. To check every option, available in securityContext, you may use

kubectl explain deployment.spec.template.spec.securityContext

As per doc

   fsGroup      <integer>
     A special supplemental group that applies to all containers in a pod. Some
     volume types allow the Kubelet to change the ownership of that volume to be
     owned by the pod: 1. The owning GID will be the FSGroup 2. The setgid bit
     is set (new files created in the volume will be owned by FSGroup) 3. The
     permission bits are OR'd with rw-rw---- If unset, the Kubelet will not
     modify the ownership and permissions of any volume.

It's usually a good idea to handle access to files via group ownership, because in restricted kubernetes configurations you can't actually control user id or group id, for example in RedHat Openshift.

What you can do is to use runAsUser, if your kubernetes provider allows it

   runAsUser    <integer>
     The UID to run the entrypoint of the container process. Defaults to user
     specified in image metadata if unspecified. May also be set in
     SecurityContext. If set in both SecurityContext and PodSecurityContext, the
     value specified in SecurityContext takes precedence for that container.

You application will work with uid you want, and naturally will create and access files as you want. As noted earlier, it's usually not the best idea to do it that way, because it makes distribution of your applications harder on different platforms.

Mounting kubernetes volume with User permission

2 Answers2