how to mount volumes as non-root on kubernetes

Question

I am trying to create a statefulset that runs zookeper, but I want it to run as non-root (i.e. under the zookeper user).
This is the image used for this:

https://github.com/kubernetes-retired/contrib/blob/master/statefulsets/zookeeper/Dockerfile

This is how I am trying to mount the volumes (Apparently I need a init container according to this):

      initContainers:
      # Changes username for volumes
      - name: changes-username
        image: busybox
        command:
        - /bin/sh
        - -c
        - |
          chown -R 1000:1000 /var/lib/zookeeper /etc/zookeeper-conf # <<<<--- this returns
          # cannot change ownership, permission denied
          # read-only filesystem.

      containers:
      - name: zookeeper
        imagePullPolicy: IfNotPresent
        image: my-repo/k8szk:3.4.14
        command:
        - sh
        - -c
        - |
          zkGenConfig.sh # The script right here requires /var/lib/zookeper to be owned by zookeper user.
                         # Initially zookeeper user does own it as per the dockerfile above,
                         # but when mounting the volume, the directory becomes owned by root
                         # hence the script fails.
        volumeMounts:
        - name: zk-data
          mountPath: /var/lib/zookeeper
        - name: zk-log4j-config
          mountPath: /etc/zookeeper-conf

I also tried to add the securityContext: fsGroup: 1000 with no change.

China

Answer 1

This can be configured using the security context, e.g.

securityContext:
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000

Then you don't need the initContainer at all - Kubernetes will handle the recursive chown as part of making the volume ready.

One issue here is the Dockerfile linked doesn't container a USER statement, so Kubernetes doesn't know to start the pod as the correct user - the runAsUser will fix that.

The reason the initContainer hack you're trying isn't working is because you're also trying to change the ownership of the read-only config directory. ConfigMaps are mounted read-only, you can't chown them. (This used to be different, but was changed for security reasons)

Sherman

Do you know how to still has sudo privileges inside container after setup securityContext? – Tenure

Important note: if you try and set fsGroup on the container securityContext, it won't work. You need to set it on the pod level securityContext. – Thisbee