Лучшая практика — предоставлять только необходимые разрешения пользователям и модулям кластера Kubernetes?

Question

Несмотря на то, что я новичок в кластерах Kubernetes, мне поручили развернуть и администрировать один для моей лаборатории. На данный момент поды с контейнерами Pytorch, использующие GPU (это будет наиболее типичный тип подов для развертывания в моих настройках), работают отлично в кластере, несмотря на некоторые проблемы с разрешениями:

1. Например , один пользователь tomможет удалить модули, развернутые другим пользователем 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 предоставляет мне оружие для решения этих проблем, если быть точным,РБАКиКонтекст безопасности. Похоже, что первую проблему можно решить, создав несколько пространств имен или иерархических пространств и настроив правильные разрешения для пространств имен для разных ролей, но я пока не уверен, что это сработает.

Однако, что касается 2-й проблемы, контекст безопасности позволяет контейнерам работать в некорневом режиме с доступом только к определенным файлам, несмотря на то, что некоторые (на самом деле, слишком многие, извлеченные из Интернета) образы должны работать в корневом режиме, поэтому требуется пересборка. Однако, похоже, что в конечном итоге мне придется рассчитывать на хорошее поведение пользователя, чтобы развернуть только модули с правильным securityContextполем в манифесте.

Как администратор кластера, что я могу сделать, чтобы избежать вышеупомянутых 2 проблем с разрешениями? Есть ли плагины Kubernetes, которые позволят мне автоматически обрабатывать разрешения? Или, когда все варианты исчерпаны, мне следует развернуть общесистемную программу, которая перехватывает каждую kubectl applyкоманду, перезаписывает манифест и применяет измененную версию?