Kubernetes挂载EFS非root用户写入报Access Denied如何解决

核心原因：Kubernetes 1.21版本配套的aws-efs-csi-driver默认关闭了挂载后自动修改根目录属主/权限的逻辑，和1.19版本集群配套的旧版驱动行为存在差异；不使用Access Point时，EFS作为NFS存储完全遵循POSIX权限规则，默认挂载后根目录属主为root，非root用户自然无写入权限。之前配置Access Point未生效，是因为仅在AWS侧创建资源但未在PV挂载参数中指定对应Access Point ID，驱动不会自动识别该配置。

可选择的修复方案 #

• 方案1：通过PV挂载参数固定目录属主权限
  编辑已创建的静态PV资源，在spec.mountOptions字段下补充权限相关参数，示例如下：

  spec:
    mountOptions:
      - tls
      - uid=1000
      - gid=1000
      - filemode=755
      - dirmode=755
  

  参数中uid和gid替换为业务容器实际运行的非root用户ID，配置完成后删除原有Pod重新触发挂载，挂载完成后目录属主会自动匹配指定用户，无需额外操作即可正常写入。该方案不需要依赖Access Point，完全适配静态配置场景。
• 方案2：通过Init容器初始化目录权限
  如果不希望修改PV配置，可以在工作负载YAML中增加初始化容器，在业务容器启动前完成目录权限修正：

  initContainers:
  - name: fix-efs-permission
    image: busybox:stable
    command: ["sh", "-c", "chown 1000:1000 /mount-path && chmod 755 /mount-path"]
    volumeMounts:
    - name: your-efs-volume-name
      mountPath: /mount-path
    securityContext:
      runAsUser: 0
  

  将配置中的挂载路径、卷名、UID/GID替换为实际业务值即可，Init容器执行完成退出后，业务容器用非root用户启动即可正常读写。
• 方案3：正确配置Access Point生效
  若要使用Access Point做权限映射，除了在AWS控制台创建时指定UID=1000、GID=1000、根目录权限755之外，还需要在PV的mountOptions中增加accesspoint=<你的Access Point ID>参数（格式为fsap-开头的字符串），驱动挂载时才会接入对应Access Point的权限规则，否则创建的Access Point不会对挂载行为生效。

避坑说明 #

• 不建议直接将EFS根目录权限设置为777，会带来多租户场景下的越权访问风险
• 多Pod同时写入EFS时，需要保证所有Pod的运行用户UID/GID保持一致，否则会出现单个Pod写入的文件其他Pod无权限操作的问题
• 集群从1.19升级到1.21后EFS CSI驱动版本同步升级，默认权限逻辑变化导致的配置失效属于正常现象，不是配置错误

内容的提问来源于stack exchange，提问作者robliv