¿La mejor práctica es otorgar solo los permisos necesarios a los usuarios y pods del clúster de Kubernetes?

¿La mejor práctica es otorgar solo los permisos necesarios a los usuarios y pods del clúster de Kubernetes?

Aunque soy nuevo en los clústeres de Kubernetes, se me ha asignado la tarea de implementar y administrar uno para mi laboratorio. Por ahora, los pods con contenedores pytorch que usan gpus (esos serán el tipo más típico de pods que se implementarán en mi configuración) se ejecutan perfectamente en el clúster, a pesar de algunos problemas de permisos:

  1. Un usuario, tompor ejemplo, puede eliminar pods implementados por otro usuario jerry.
  2. Los contenedores se ejecutan como root. De nuevo, tomemos jerrypor ejemplo. Supongamos que jerryse implementa un pod manifestado con contenedores que montan un directorio con archivos propiedad de otros usuarios. Ejecutar como rootmedio jerryno solo puede modificar sus propios archivos, sino también los archivos propiedad de tom, incluso de spikey tyke. Un manifiesto de este tipo probablemente se vería así:
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.

En realidad, Kubernetes me proporciona armas para abordar estos problemas, para ser precisos,RBACyContexto de seguridad. Parece que el primer problema se puede solucionar creando múltiples espacios de nombres o jerárquicos y configurando los permisos correctos para los espacios de nombres para diferentes roles, pero todavía no estoy seguro de que eso funcione.

Sin embargo, en cuanto al segundo problema, un contexto de seguridad permite que los contenedores se ejecuten en modo no raíz con acceso solo a ciertos archivos, a pesar de que algunas imágenes (de hecho, demasiadas extraídas de Internet) deben ejecutarse de manera raíz, por lo que necesitan una reconstrucción. . Sin embargo, parece que, en última instancia, tengo que contar con la buena conducta del usuario para implementar solo pods con securityContextel campo correcto en el manifiesto.

Como administrador de clúster, ¿qué puedo hacer para evitar los dos problemas de permisos antes mencionados? ¿Existe algún complemento de Kubernetes que me permita procesar los permisos automáticamente? O cuando se agoten todas las opciones, ¿debería implementar un programa para todo el sistema que intercepte cada kubectl applycomando, sobrescriba el manifiesto y aplique la versión modificada?

información relacionada