Security context not respected

[unguiculus]

I'm trying to use local-path-provisioner with kind. While it seems to generally work with multi-node clusters, security contexts are not respected. Volumes are always mounted with root as group. Here's a simple example that demonstrates this:

apiVersion: v1
kind: Pod
metadata:
  name: local-path-test
  labels:
    app.kubernetes.io/name: local-path-test
spec:
  containers:
    - name: test
      image: busybox
      command:
        - /config/test.sh
      volumeMounts:
        - name: test
          mountPath: /test
        - name: config
          mountPath: /config
  securityContext:
    fsGroup: 1000
    runAsNonRoot: true
    runAsUser: 1000
  terminationGracePeriodSeconds: 0
  volumes:
    - name: test
      persistentVolumeClaim:
        claimName: local-path-test
    - name: config
      configMap:
        name: local-path-test
        defaultMode: 0555

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: local-path-test
  labels:
    app.kubernetes.io/name: local-path-test
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: "1Gi"
  storageClassName: local-path

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: local-path-test
  labels:
    app.kubernetes.io/name: local-path-test
data:
  test.sh: |
    #!/bin/sh

    ls -al /test

    echo 'Hello from local-path-test'
    cp /config/text.txt /test/test.txt
    touch /test/foo

  text.txt: |
    some test content

Here's the log from the container:

total 4
drwxr-xr-x    2 root     root            40 Feb 22 09:50 .
drwxr-xr-x    1 root     root          4096 Feb 22 09:50 ..
Hello from local-path-test
cp: can't create '/test/test.txt': Permission denied
touch: /test/foo: Permission denied

As can be seen, the mounted volume has root as group instead of 1000 as specified by the security context. I also installed local-path-provisioner on Docker4Mac. The result is the same, so it is not a kind issue. Using the default storage class on Docker4Mac, it works as expected.

[rimusz]

yes, I can confirm that too!

[aojea]

As can be seen, the mounted volume has root as group instead of 1000 as specified by the security context. I also installed local-path-provisioner on Docker4Mac. The result is the same, so it is not a kind issue. Using the default storage class on Docker4Mac, it works as expected.

I verified that the security context work in kind, at least these examples work https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

[unguiculus]

@aojea The examples there don't use PVCs.

[aojea]

yeah, just wanted to confirm that security context works under kind 😅 , so the problem has to be in the provisioner

[yasker]

@unguiculus @rimusz Unfortunately, it's something outside of provisioner's control. It's kubelet who created the directory.

The hostpath type PV doesn't support security context. It has to be root for the volume to be written in. See kubernetes/minikube#1990 and https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/storage/volumes/#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

At the end of kubernetes/minikube#1990 there is a workaround provided.

I also found a PR to add fsGroup support to hostpath volume, but it wasn't accepted. kubernetes/kubernetes#39438

[BenTheElder]

This is unfortunate :(

Does the security group info at least make it to the provisioner? We could probably fix this in a similar way to how cleanup is handled?

side note: It might be nice to make the image used for cleanup configurable, we can probably use one of the standard kubernetes images in many cases to avoid needing another image to be pulled 😅 (and use a specific version to avoid :latest-> pull image).

[yasker]

@BenTheElder Yeah this should work. Let me give it a try.

[yasker]

@BenTheElder @unguiculus @rimusz Alright, v0.0.3 has been released and the issue with security context should be fixed.

@BenTheElder I've also thrown in an option for "helper image", which used for creating and deleting (cleanup) directories on the node now.

[BenTheElder]

Very cool, thank you!

[jamesgoodhouse]

Hate to ping on a super old issue, but there's #41 that seems to be the same thing that was fixed in this issue. Is this an entirely different thing? I'm currently experiencing troubles getting fsGroup to be respected, even though my config looks very similar to the example one contained in the fix (3256bdf).