如何允许非根用户写入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 (https://github.com/kubernetes-sigs/aws-efs-csi-driver/tree/master/examples/kubernetes/multiple_豆荚)中的示例，适当地更新了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

如果以后有人遇到这种情况，我通过为任何需要写入文件系统的Pod使用initContainer来解决我的问题。

例如：

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:
      runAsGroup: 1337
  initContainers:
  - name: fs-owner-change
    image: busybox
    command:
    - chown
    - "root:1337"
    - "/efs-fs"
    volumeMounts:
    - mountPath: /efs-fs
      name: persistent-storage
  securityContext:
    fsGroup: 1337
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: efs-claim

其余的定义与我问题中的内容相符。

就像@JerryChen建议的那样(“使用访问点”)，我发现如果我只使用一个动态配置EFS (它确实利用EFS访问点来允许对EFS实例的共享访问)，那么事情就更简单了。下面是StorageClass、PersistentVolumeClaim和一个实例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

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

runAsUser只用于确保非根用户执行busybox命令。

这可能比暴力强制使用initContainer的文件系统权限更好。

Answer 2

您应该尝试EFS，https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html中的接入点。

它强制执行操作系统用户和组，以及通过访问点发出的每个文件系统请求的目录。

换句话说，您可以将路径设置为uid 1337和gid 1337。