如何允许非根用户写入EKS中安装的EFS。

Question

我在配置静态配置的EFS时遇到了问题，这样多个作为非根用户运行的荚就可以读写文件系统了。

我正在使用AWS EFS CSI驱动程序。我的版本信息如下：

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.18", GitCommit:"6f6ce59dc8fefde25a3ba0ef0047f4ec6662ef24", GitTreeState:"clean", BuildDate:"2021-04-15T03:31:30Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.9-eks-d1db3c", GitCommit:"d1db3c46e55f95d6a7d3e5578689371318f95ff9", GitTreeState:"clean", BuildDate:"2020-10-20T22:53:22Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

我学习了github (豆荚)中的示例，适当地更新了volumeHandle。示例规范中定义的busybox容器能够读取和写入文件系统，但当我将相同的PVC添加到不作为根用户运行的pod中时，pod无法写入安装的EFS。我尝试了一些其他的方法来让它像我所期望的那样运作：

• 只需将这里描述的注释：https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#access-control应用于持久卷定义。
• 应用上述注释并将securityContext.runAsGroup包含到pod定义中(具有适当的值)
• 应用注释、runAsGroup以及Pod的fsGroup

这些配置都不允许非根用户向已挂载的EFS写入。在配置静态配置的EFS以使多个荚(所有这些都以非根用户的身份运行)可以在挂载的EFS中读写方面，我缺少了什么？

以下是pod的定义，供参考：

apiVersion: v1
kind: Pod
metadata:
  name: app1
spec:
  containers:
  - name: app1
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out1.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: efs-claim
---
apiVersion: v1
kind: Pod
metadata:
  name: app2
spec:
  containers:
  - name: app2
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out2.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: efs-claim
---
apiVersion: v1
kind: Pod
metadata:
  name: app3
spec:
  containers:
  - name: app3
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out3.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  securityContext:
    runAsUser: 1000
    runAsGroup: 1337
    fsGroup: 1337
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: efs-claim

以及SC/PVC/PV：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc
  resources:
    requests:
      storage: 5Gi  
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
  annotations:
    pv.beta.kubernetes.io/gid: {{ .Values.groupId | quote }}
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-asdf123

Answer 1

我想出了解决这个问题的两种方法，并认为我应该更新它，以防其他人遇到同样的问题。

第一种可能更好的方法是只使用动态配置EFS PersistentVolume。通过这种方式，所有利用PersistentVolumeClaim的容器都可以在EFS中创建一个共享的访问点。

这里有一个StorageClass、PersistentVolumeClaim和一个利用PVC的吊舱的例子。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId:  {{ .Values.efsVolumeHandle }}
  directoryPerms: "775"
reclaimPolicy: Retain
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc
  resources:
    requests:
      storage: 5Gi  # Not actually used - see https://aws.amazon.com/blogs/containers/introducing-efs-csi-dynamic-provisioning/
---
apiVersion: v1
kind: Pod
metadata:
  name: app3
spec:
  containers:
  - name: app3
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out3.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  securityContext:
    runAsUser: 1000
    runAsGroup: 1337
    fsGroup: 1337
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: efs-claim

注意directoryPerms (775)在StorageClass中指定，以及在Pod中指定的runAsGroup和fsGroup。在以非根用户的身份运行的Pod中使用此PVC时，共享用户组号是关键。

指定runAsUser只是为了确保busybox内容不以root形式运行。

第二种方法是我最初想出来的，很可能是“核”选项，但它适用于静态提供的EFS。

为了简洁起见，我省略了豆荚定义的其余部分。您可以使用initContainer来确保在挂载的EFS卷上设置了某些权限。

      initContainers:
      - name: fs-permission-update
        image: busybox
        command:
        - chown
        - "root:{{ .Values.groupId }}"
        - "/efs-fs"
        volumeMounts:
        - mountPath: /efs-fs
          name: efs-storage

同样，请确保任何挂载卷并作为非根用户运行的Pod都使用fsGroup和runAsGroup来确保用户是允许的用户组的一部分。

总之，可能不要使用静态配置的EFS，而是使用动态配置的EFS。请注意，这是针对Kubernetes的EFS CSI驱动程序的。有关更多示例和一些其他细节，请查看CSI驱动程序GitHub。