Prática recomendada para conceder apenas as permissões necessárias aos usuários e pods do cluster Kubernetes?

Prática recomendada para conceder apenas as permissões necessárias aos usuários e pods do cluster Kubernetes?

Mesmo sendo novo em clusters Kubernetes, fui designado para implantar e administrar um em meu laboratório. Por enquanto, pods com contêineres pytorch usando gpus (esses serão os tipos mais típicos de pods a serem implantados em minhas configurações) estão funcionando perfeitamente no cluster, apesar de alguns problemas de permissão:

  1. Um usuário, tompor exemplo, pode excluir pods implantados por outro usuário, jerrypor exemplo.
  2. Os contêineres estão sendo executados como root. Novamente, tomemos jerrypor exemplo. Suponha que jerryele implemente um pod manifestado com contêineres que montam um diretório com arquivos de propriedade de vários outros usuários. Executar como rootmeio jerrypode não apenas modificar seus próprios arquivos, mas também arquivos de propriedade de tom, até mesmo de spikee tyke. Esse manifesto provavelmente seria assim:
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.

Na verdade, o Kubernetes me fornece armas para resolver esses problemas, para ser mais preciso,RBACeContexto de segurança. Parece que o primeiro problema pode ser resolvido criando vários namespaces ou hierárquicos e configurando permissões corretas para namespaces para diferentes funções, mas ainda não tenho certeza se isso funcionará.

No entanto, quanto à segunda questão, um contexto de segurança permite que os contêineres sejam executados em modo não-root com acesso apenas a determinados arquivos, apesar de algumas imagens (na verdade, muitas extraídas da Internet) terem que ser executadas com root, portanto, precisam de uma reconstrução . No entanto, parece que devo contar com a boa conduta do usuário para implantar apenas pods com securityContexto campo correto no manifesto.

Como administrador de cluster, o que posso fazer para evitar os dois problemas de permissão mencionados acima? Existe algum plug-in do Kubernetes para eu processar as permissões automaticamente? Ou quando todas as opções estiverem esgotadas, devo implantar um programa para todo o sistema que intercepte todos kubectl applyos comandos, substitua o manifesto e aplique a versão modificada?

informação relacionada