如何允许非 root 用户写入 EKS 中已安装的 EFS

如何解决如何允许非 root 用户写入 EKS 中已安装的 EFS

我在配置静态配置的 EFS 时遇到问题，以便以非 root 用户身份运行的多个 Pod 可以读写文件系统。

我正在使用 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",BuildDate:"2020-10-20T22:53:22Z",Platform:"linux/amd64"}

我按照 github 存储库 (https://github.com/kubernetes-sigs/aws-efs-csi-driver/tree/master/examples/kubernetes/multiple_pods) 中的示例正确更新了 volumeHandle。该示例的规范中定义的 busyBox 容器能够读取和写入文件系统，但是当我将相同的 PVC 添加到不以 root 用户身份运行的 pod 时，该 pod 无法写入已安装的 EFS。我已经尝试了一些其他的方法来让它按我预期的那样工作：

只需将此处描述的注释：https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#access-control 应用于持久卷定义。
应用上述注释并将 securityContext.runAsGroup 包含到 pod 定义（具有适当的值）
为 Pod 应用注解、runAsGroup 和 fsGroup

这些配置都不允许非 root 用户写入已安装的 EFS。在配置静态配置的 EFS 以便多个 pod（所有这些都以非 root 用户身份运行）可以在挂载的 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

解决方法

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

第一种可能更好的方法是使用 dynamically provisioned EFS PersistentVolume。这种方式在 EFS 中创建了一个访问点，该访问点由使用 PersistentVolumeClaim 的所有容器共享。

以下是 StorageClass、PersistentVolumeClaim 和使用 PVC 的 pod 的示例。

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

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

runAsUser 仅用于确保 busybox 内容不会以 root 身份运行

第二种方法是我最初制定的，可能是“核”选项，但适用于静态配置的 EFS。

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

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

再次确保任何挂载卷并以非 root 用户身份运行的 Pod 使用 fsGroup 和 runAsGroup 以确保用户是允许的用户组的一部分。

总而言之，可能不要使用静态配置的 EFS，而是使用动态配置的 EFS。请注意，这特定于 Kubernetes 的 EFS CSI 驱动程序。查看 EKS CSI Driver GitHub 以获取更多示例和一些其他详细信息。