在 Pod 上挂载外部 NFS 共享并拒绝访问文件的权限

Question

我已经尝试阅读 Stack Overflow 中的所有问题和答案，并进行了大量谷歌搜索，询问了我周围的一些 Kubernetes 专家，但没有找到……我对这个问题感到很疯狂。 ..

这是我的问题，我们有多个环境，有不同的租户，每个环境都有一个 NFS 服务器（在 AIX、Solaris、Linux、Windows、...取决于租客）。并希望在特定 POD 上的 Kubernetes 部署中挂载 NFS 共享。

现在，这行得通，我们可以使用 NFS V4 挂载 NFS 共享。这适用于我们每个外部 NFS 服务器。

我正在使用 Kubernetes Provisioner (https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner) 并且可以正常工作。

以下是我的配置以使其工作：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-xy-provisioner
  labels:
    app: nfs-xy-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-xy-provisioner
  template:
    metadata:
      labels:
        app: nfs-xy-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-xy-provisioner
          image: XYZ/k8s-staging-sig-storage/nfs-subdir-external-provisioner:v4.0.2
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-xxx-xy-provisioner
            - name: NFS_SERVER
              value: myServer.example.com
            - name: NFS_PATH
              value:  /my/path/xy_eingang
      volumes:
        - name: nfs-client-root
          nfs:
            server: myServer.example.com
            path: /my/path/xy_eingang

具有以下存储类：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-xxx-xy-nfs-storage
provisioner: k8s-sigs.io/nfs-xxx-xy-provisioner
parameters:
  pathPattern: ""
  archiveOnDelete: "false"
reclaimPolicy: Retain

具有以下 pv 声明

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-xy-pvc
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-xxx-xy-nfs-storage"
spec:
  storageClassName: "managed-xxx-xy-nfs-storage"
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

pod中的挂载：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  template:
    spec:
      volumes:
        - name: app-xy
          persistentVolumeClaim:
            claimName: app-xy-pvc    
      containers:
        - name: app
          volumeMounts:
            - name: app-xy
              mountPath: /my/pod/path/xy

这是坐骑

myServer.example.com:/my/path/xy_eingang on /my/pod/path/xy type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=1.2.3.4,local_lock=none,addr=2.3.4.5)

现在当我在挂载路径上时，我可以看到以下内容：

drwxrws--- 3 65534 4294967294  73728 Jul  2 07:52 33
drwxrws--- 2 65534 4294967294  69632 Jul  2 07:52 44
drwxrws--- 2 65534 4294967294  90112 Jul  2 07:52 55
-rwxrws--- 1 65534 4294967294 630793 Oct 20  2014 5905001_00001.ZIP

所以我们有 UID=65534 和 GID=4294967294。我试图将 fsgroup 或 supplementalGroups 更改为 4294967294，但 kubernetes 抱怨说它只能使用 0 到 2147483647 之间的数字。

在我们的 NFS 服务器上（在那个例子中），我们有以下 user/group：

用户：usernfs (UID=56008)
群组：usernfs (GID=56001)

而且这个nfs映射没有做，在pod中，由于只是运行的应用，idmapd没有启动。据我了解，挂载是在节点上完成的，然后在 pod 中我们只有来自节点的挂载。

而且我们不是 kubernetes 安装的所有者，我们是简单的用户，我们无法更改 Kubernetes 上的任何内容 configuration/nodes，等等...我们是使用 Kubernetes 功能的简单“用户”部署我们的应用程序。我们不能使用 Helm，我们唯一可以使用的是 Kustomize。

出于安全原因，我们无法将 NFS 服务器上的权限更改为 777/644/744/666 等。所以所有更改共享磁盘权限的建议对我们都不起作用。

我试过改成NFS V3，但是从安全的角度来说，我们的安全团队不想使用这么老的协议，所以我们必须使用NFS V4。

我知道对于 NFS V4，我们需要 idmapd 运行ning，但我不知道我们需要在哪里，在节点上，在 pod 上，还是在其他地方？不知道，我是 Kubernetes 的新手，我可以在几分钟内完成的事情需要我几周的时间才能完成（比如这个问题）而且我找不到解决该问题的方法。

因此，欢迎任何帮助来解决该权限问题...

Kubernetes版本如下：

Client Version: version.Info{
  Major:"1", 
  Minor:"18", 
  GitVersion:"v1.18.12",
  GitCommit:"7cd5e9086de8ae25d6a1514d0c87bac67ca4a481",
  GitTreeState:"clean",
  BuildDate:"2020-11-12T09:18:55Z",
  GoVersion:"go1.13.15",
  Compiler:"gc",
  Platform:"linux/amd64"
}

Server Version: version.Info{
  Major:"1",
  Minor:"19",
  GitVersion:"v1.19.9+vmware.1",
  GitCommit:"f856d899461199c512c21d0fdc67d49cc70a8963",
  GitTreeState:"clean", BuildDate:"2021-03-19T23:57:11Z",
  GoVersion:"go1.15.8",
  Compiler:"gc",
  Platform:"linux/amd64"
}

亲切的问候，亚历山德罗

Answer 1

我知道这有多令人沮丧，我在 centos 8 上使用过它，Ubuntu 18、20 在 baremetal 和 digital ocean 上使用过，我们必须在主机服务器上安装 nfs 工具，比它像魅力。我们甚至不必触及用户安全 uuid 等

在 Pod 上挂载外部 NFS 共享并拒绝访问文件的权限

Mounting External NFS share on Pod and permission denied to access files

kubernetes

nfs

kustomize