CODEWITHSUNDEEP
kubernetespersistent-volumespersistent-volume-claims
toto
toto

Reputation: 1377

Mounting kubernetes volume with User permission

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. :/

Upvotes: 4

Views: 19688

Answers (3)

Zeedia
Zeedia

Reputation: 1483

Another way to set user/group or permissions is using preStart hook. From the documentation, preStart will be executed after the pod is created.

lifecycle:
  postStart:
    exec:
        command: ["/bin/sh", "-c", "WHATEVER BASH COMMAND YOU NEED TO ON YOUR POD"]

Upvotes: 0

rock'n rolla
rock'n rolla

Reputation: 2229

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

Permissions would end up looking like this

Upvotes: 8

Andrew
Andrew

Reputation: 4622

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.

Upvotes: 2

Related Questions