Kubernetes fsGroup not changing file ownership on PersistentVolume

user_318558 0
Viewed 1941

On the host, everything in the mounted directory (/opt/testpod) is owned by uid=0 gid=0. I need those files to be owned by whatever the container decides, i.e. a different gid, to be able to write there. Resources I'm testing with:

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv
  labels:
    name: pv
spec:
  storageClassName: manual
  capacity:
    storage: 10Mi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/opt/testpod"

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
spec:
  storageClassName: manual
  selector:
    matchLabels:
      name: pv
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Mi

---
apiVersion: v1
kind: Pod
metadata:
  name: testpod
spec:
  nodeSelector:
    foo: bar
  securityContext:
    runAsUser: 500
    runAsGroup: 500
    fsGroup: 500
  volumes:
  - name: vol
    persistentVolumeClaim:
      claimName: pvc
  containers:
  - name: testpod
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: vol
      mountPath: /data

After the pod is running, I kubectl exec into it and ls -la /data shows everything still owned by gid=0. According to some Kuber docs, fsGroup is supposed to chown everything on the pod start but it doesn't happen. What am I doing wrong please?

kubernetes
1 Answers

The hostpath type PV doesn't support security context. You have to be root for the volume to be written in. It is described well in this github issue and this docs about hostPath:

The directories created on the underlying hosts are only writable by root. You either need to run your process as root in a privileged container or modify the file permissions on the host to be able to write to a hostPath volume

You may also want to check this github request describing why changing permission of host directory is dangerous.

The workaround people describe that it appears to be working is to grant your user sudo privileges but that actually makes the idea of running container as non root user useless.

Security context appears to be working well with emptyDir volume (described well in the k8s docs here)

user_121865850
Related