无需privileged或SYS_ADMIN权限在K8s Pod内安全挂载镜像共享的方案

你提到的privileged: true或全量添加SYS_ADMIN权能确实权限过大，存在容器逃逸、节点配置被篡改的风险，不需要依赖这类高权配置，有三个生产可落地的方案：

• 基于FUSE实现用户空间挂载
  所有基于FUSE框架的文件系统（包括sshfs、JuiceFS、s3fs等），不需要容器持有全局SYS_ADMIN权限，只需要做最小配置即可正常挂载：
  1. 在Pod定义中把节点的/dev/fuse设备以可读可写权限挂载到容器内
  2. 配置seccomp白名单放开mount、umount2、fusermount相关的必要系统调用
  3. 不需要开启特权模式，也不需要给容器加全量SYS_ADMIN，所有操作被限制在/dev/fuse设备的访问范围内，安全风险极低。
• CSI边车代理挂载
  把挂载逻辑从业务容器剥离，作为同Pod下的独立边车容器运行：
  1. 边车容器仅授予挂载对应存储需要的最小权限，可配合用户命名空间把权限范围严格锁死在Pod自身的命名空间内，不会影响节点
  2. 业务容器和边车共享一个emptyDir类型的卷，边车完成存储挂载后把内容写入共享目录，业务容器直接读写该目录即可，全程业务容器不需要配置任何特殊securityContext规则
     这是目前生产环境最推荐的方案，权限边界最清晰，符合最小权限原则。
• 高版本内核非特权命名空间挂载
  如果集群节点内核版本>=5.11，且K8s版本>=1.25（用户命名空间特性已GA），只需要开启Pod的用户命名空间配置，容器就可以在自身的挂载命名空间内执行非特权挂载，不需要任何节点级别的高权：

  spec:
    hostUsers: false
    containers:
    - name: your-app
      securityContext:
        runAsNonRoot: true
        allowPrivilegeEscalation: false
  

  该模式下容器内的所有挂载操作仅在当前Pod的命名空间内生效，不会穿透到节点或其他Pod，完全规避了传统SYS_ADMIN配置带来的逃逸风险。注意该方案对挂载的文件系统类型有一定限制，不支持直接挂载节点块设备，常规的bind挂载、tmpfs挂载、网络文件系统挂载均可正常支持。

注意：所有方案都需要严格配置seccomp、AppArmor/SELinux规则做权限兜底，禁止放开不必要的系统调用权限。

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