CODEWITHSUNDEEP
kubernetesamazon-eks
mike
mike

Reputation: 175

How can I give my non-root user write permissions on a kubernetes volume mount?

From my understanding (based on this guide https://snyk.io/blog/10-kubernetes-security-context-settings-you-should-understand/), if I have the following security context specified for some kubernetes pod

securityContext:
  # Enforce to be run as non-root user
  runAsNonRoot: true
  # Random values should be fine
  runAsUser: 1001
  runAsGroup: 1001
  # Automatically convert mounts to user group
  fsGroup: 1001
  # For whatever reasons this is not working
  fsGroupChangePolicy: "Always"

I expect this pod to be run as user 1001 with the group 1001. This is working as expected, because running id in the container results in: uid=1001 gid=1001 groups=1001.

The file system of all mounts should automatically be accessible by user group 1001, because we specified fsGroup and fsGroupChangePolicy. I guess that this also works because when running ls -l in one of the mounted folders, I can see that the access rights for the files look like this: -rw-r--r-- 1 50004 50004. Ownership is still with the uid and gid it was initialised with but I can see that the file is now readable for others.

The question now is how can I add write permission for my fsGroup those seem to still be missing?

Upvotes: 1

Views: 5545

Answers (1)

ishuar
ishuar

Reputation: 1328

You need to add an additional init_container in your pod/deployment/{supported_kinds} with the commands to give/change the permissions on the volume mounted on the pod to the userID which container is using while running.

 initContainers:
  - name: volumepermissions
    image: busybox ## any image having linux utilities mkdir,echo,chown will work.
    imagePullPolicy: IfNotPresent
    env:
      - name: "VOLUME_DATA_DIR"
        value: mountpath_for_the_volume
    command:
      - sh
      - -c
      - |
        mkdir -p $VOLUME_DATA_DIR
        chown -R 1001:1001 $VOLUME_DATA_DIR 

        echo 'Volume permissions OK ✓'
    volumeMounts:
      - name: data
        mountPath: mountpath_for_the_volume

This is necessary when a container in a pod is running as a user other than root and needs write permissions on a mounted volume.

if this is a helm template this init container can be created as a template and used in all the pods/deployments/{supported kinds} to change the volume permissions.

Update: As mentioned by @The Fool, it should be working as per the current setup if you are using Kubernetes v1.23 or greater. After v1.23 securityContext.fsGroup and securityContext.fsGroupChangePolicy features went into GA/stable.

Upvotes: 2

Related Questions