AWS, EFS, EKS, Mount volume as root - kubernetes

Question

I'm trying to mount a volume as root.
I am using aws-efs-csi-driver v1.3.0 on Kubernetes 1.17 in EKS and trying to use Dynamic Provisioning.
My issue is that no matter how I try to specify the UID/GID, it still creates it with a dynamically allocated UID and GID.
Here are my resources:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: test-sc
provisioner: efs.csi.aws.com
parameters:
provisioningMode: efs-ap
fileSystemId: fs-ddd8b9e9
directoryPerms: "775"
uid: "0"
gid: "0"
reclaimPolicy: Retain
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: test-sc
resources:
requests:
storage: 50Gi
---
kind: Deployment
apiVersion: apps/v1
metadata:
name: test
labels:
app: test
spec:
strategy:
type: Recreate
selector:
matchLabels:
app: test
replicas: 1
template:
metadata:
name: test
labels:
app: test
spec:
containers:
- name: test
image: ubuntu:latest
command: [ "/bin/sh" ]
args: [ "-c", "while true; do echo $(date -u) >> /example/out.txt; sleep 5; done" ]
imagePullPolicy: Always
volumeMounts:
- name: test-data
mountPath: /data
securityContext:
runAsUser: 0
runAsGroup: 0
fsGroup: 0
volumes:
- name: test-data
persistentVolumeClaim:
claimName: test-pvc
My issue is that I want the data directory to have the root:root permissions, and not the dynamically allocated permissions (50004:50004 in this case)
❯ kubectl exec -it test-9588c455c-qqdw6 -- bash
root#test-9588c455c-qqdw6:/# ls -las
total 4
0 drwxr-xr-x 1 root root 29 Oct 15 09:44 .
0 drwxr-xr-x 1 root root 29 Oct 15 09:44 ..
0 -rwxr-xr-x 1 root root 0 Oct 15 09:44 .dockerenv
0 lrwxrwxrwx 1 root root 7 Sep 21 16:48 bin -> usr/bin
0 drwxr-xr-x 2 root root 6 Apr 15 2020 boot
4 drwxrwxr-x 2 50004 50004 6144 Oct 15 09:44 data
0 drwxr-xr-x 5 root root 360 Oct 15 09:44 dev
0 drwxr-xr-x 1 root root 66 Oct 15 09:44 etc
0 drwxr-xr-x 2 root root 6 Apr 15 2020 home
0 lrwxrwxrwx 1 root root 7 Sep 21 16:48 lib -> usr/lib
0 lrwxrwxrwx 1 root root 9 Sep 21 16:48 lib32 -> usr/lib32
0 lrwxrwxrwx 1 root root 9 Sep 21 16:48 lib64 -> usr/lib64
0 lrwxrwxrwx 1 root root 10 Sep 21 16:48 libx32 -> usr/libx32
0 drwxr-xr-x 2 root root 6 Sep 21 16:48 media
0 drwxr-xr-x 2 root root 6 Sep 21 16:48 mnt
0 drwxr-xr-x 2 root root 6 Sep 21 16:48 opt
0 dr-xr-xr-x 415 root root 0 Oct 15 09:44 proc
0 drwx------ 2 root root 37 Sep 21 17:00 root
0 drwxr-xr-x 1 root root 21 Oct 15 09:44 run
0 lrwxrwxrwx 1 root root 8 Sep 21 16:48 sbin -> usr/sbin
0 drwxr-xr-x 2 root root 6 Sep 21 16:48 srv
0 dr-xr-xr-x 13 root root 0 Jun 11 09:16 sys
0 drwxrwxrwt 2 root root 6 Sep 21 17:00 tmp
0 drwxr-xr-x 13 root root 145 Sep 21 16:48 usr
0 drwxr-xr-x 11 root root 139 Sep 21 17:00 var
root#test-9588c455c-qqdw6:/# exit

Answer 1

Indeed annoying... in short, the UID/GID we specified will be ignored. Please take a look here. If your workload requires same UID/GID as the mounted volume, a workaround is add code to runas the same UID/GID as the mounted volume in entrypoint script.