☰

仅向 Kubernetes 集群用户和 Pod 授予必要的权限的最佳实践？

tag-icon • tag-icon kubernetes kubectl
仅向 Kubernetes 集群用户和 Pod 授予必要的权限的最佳实践？

尽管我是 Kubernetes 集群的新手，但我还是被指派为我的实验室部署和管理一个集群。目前，带有使用 gpu 的 pytorch 容器的 pod（这些将是我设置中最典型的 pod 类型）在集群上运行良好，尽管存在一些权限问题：

  1. 例如，一个用户tom可以删除另一个用户部署的 pod jerry。
  2. 容器以 的身份运行root。我们再举jerry个例子。假设jerry部署了一个 pod，其容器清单中挂载了一个目录，其中包含其他用户拥有的文件。以 身份运行意味着root不仅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和安全上下文。似乎可以通过创建多个命名空间或分层命名空间并为不同角色配置正确的命名空间权限来解决第一个问题，但我还不确定这是否有效。

但是，对于第二个问题，安全上下文允许容器以非 root 模式运行，并且只能访问某些文件，尽管有些（实际上，从互联网上拉取的太多）镜像必须以 root 模式运行，因此需要重建。但是，似乎我最终只能依靠用户的良好行为来仅部署securityContext清单中具有正确字段的 pod。

作为集群管理员，我该怎么做才能避免上述 2 个权限问题？是否有任何 kubernetes 插件可供我自动处理权限？或者，当所有选项都用尽时，我是否应该部署一个系统范围的程序来拦截每个kubectl apply命令、覆盖清单并应用修改后的版本？

相关内容