☰

僅向 Kubernetes 叢集使用者和 Pod 授予必要權限的最佳實務？

tag-icon • tag-icon kubernetes kubectl
僅向 Kubernetes 叢集使用者和 Pod 授予必要權限的最佳實務？

儘管我是 kubernetes 叢集的新手，但我仍被指派為我的實驗室部署和管理一個叢集。目前，儘管存在一些權限問題，但帶有使用 GPU 的 pytorch 容器的 Pod（這些將是我的設定中部署的最典型的 Pod 類型）正在叢集上正常運行：

  1. 例如，一個使用者tom可以刪除另一個使用者部署的 Pod jerry。
  2. 容器以root.我們再次舉例jerry。假設jerry部署了一個包含容器的 pod，該容器掛載了包含各種其他使用者擁有的檔案的目錄。 running asroot意味著jerry不僅可以修改自己的文件，還可以修改 、tom甚至spike和擁有的文件tyke。這樣的清單可能如下：
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
  namespace: default # this field should be properly configured
  # if I want to restrict user access to certain resources,
  # usually pods.
spec:
  runtimeClassName: nvidia
  nodeSelector:
    nvidia.com/gpu: 'true'
  restartPolicy: Never
  containers:
    - name: cuda-container
      image: mylab.registry:5000/espnet/espnet:gpu-latest
      command:
      - /bin/sh
      - -c
      - |
        echo "running following scripts"
        ls /data
        ls /exp
        nvidia-smi
      resources:
        limits:
          nvidia.com/gpu: 4
      volumeMounts:
      - name: data-volume
        mountPath: /data
      - name: exp-volume
        mountPath: /exp
  volumes:
  - name: data-volume
    hostPath:
      path: /data
  - name: exp-volume
    hostPath:
      path: /exp # where directories owned by tom, jerry,
      # spike and tyke are located.
      # on the host machine, this directory is actually
      # a mounted nfs path served by other machine.

其實Kubernetes確實提供了解決這些問題的武器，準確來說，RBAC和安全情境。似乎可以透過建立多個命名空間或分層命名空間並為不同角色配置正確的命名空間權限來解決第一個問題，但我還不確定這是否有效。

然而，對於第二個問題，安全上下文允許容器以非根模式運行，只能存取某些文件，儘管一些（實際上，從互聯網上拉取的太多）圖像必須以根模式運行，因此需要重建。但是，似乎我最終必須依靠用戶的良好行為來僅部署securityContext清單中具有正確欄位的 Pod。

身為叢集管理員，我該如何避免上述兩個權限問題？有沒有 kubernetes 外掛程式可以讓我自動處理權限？或者，當每個選項都用盡時，我是否應該部署一個系統範圍的程式來攔截每個kubectl apply命令，覆蓋清單，然後應用修改後的版本？

相關內容