Ist es bewährte Methode, Kubernetes-Clusterbenutzern und -Pods nur die erforderlichen Berechtigungen zu erteilen?

Question

Obwohl ich mit Kubernetes-Clustern noch nicht vertraut bin, wurde mir die Aufgabe zugewiesen, einen für mein Labor bereitzustellen und zu verwalten. Derzeit laufen Pods mit PyTorch-Containern, die GPUs verwenden (das sind die typischsten Pod-Typen, die in meinen Einstellungen bereitgestellt werden), trotz einiger Berechtigungsprobleme einwandfrei auf dem Cluster:

1. Ein Benutzer tomkann beispielsweise Pods löschen, die von einem anderen Benutzer bereitgestellt wurden jerry.
2. Container werden als ausgeführt root. Nehmen wir noch einmal jerryals Beispiel: Angenommen, jerrystellt einen Pod bereit, der aus Containern besteht, die ein Verzeichnis mit Dateien bereitstellen, die verschiedenen anderen Benutzern gehören. Ausführen als rootbedeutet , dass nicht nur die eigenen Dateien geändert werden können, sondern auch Dateien, die , sogar und jerrygehören . Ein solches Manifest würde wahrscheinlich folgendermaßen aussehen:tomspiketyke

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.

Tatsächlich bietet mir Kubernetes Waffen, um diese Probleme anzugehen, und zwar:RBACUndSicherheitskontext. Es scheint, dass das erste Problem dadurch gelöst werden kann, dass mehrere oder hierarchische Namespaces erstellt werden und die richtigen Berechtigungen für die Namespaces für verschiedene Rollen konfiguriert werden, aber ich bin noch nicht sicher, ob das funktioniert.

Was jedoch das zweite Problem betrifft, ermöglicht ein Sicherheitskontext die Ausführung von Containern in einem Nicht-Root-Modus mit Zugriff nur auf bestimmte Dateien, obwohl einige (tatsächlich viel zu viele aus dem Internet gezogene) Images root-fähig ausgeführt werden müssen und daher neu erstellt werden müssen. Es scheint jedoch, dass ich mich letztendlich auf das gute Verhalten eines Benutzers verlassen muss, um nur Pods mit korrekten securityContextFeldern im Manifest bereitzustellen.

Was kann ich als Clusteradministrator tun, um die beiden oben genannten Berechtigungsprobleme zu vermeiden? Gibt es Kubernetes-Plugins, mit denen ich Berechtigungen automatisch verarbeiten kann? Oder sollte ich, wenn alle Optionen ausgeschöpft sind, ein systemweites Programm bereitstellen, das jeden kubectl applyBefehl abfängt, das Manifest überschreibt und stattdessen die geänderte Version anwendet?