
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:
- Um usuário,
tom
por exemplo, pode excluir pods implantados por outro usuário,jerry
por exemplo. - Os contêineres estão sendo executados como
root
. Novamente, tomemosjerry
por exemplo. Suponha quejerry
ele implemente um pod manifestado com contêineres que montam um diretório com arquivos de propriedade de vários outros usuários. Executar comoroot
meiojerry
pode não apenas modificar seus próprios arquivos, mas também arquivos de propriedade detom
, até mesmo despike
etyke
. 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 securityContext
o 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 apply
os comandos, substitua o manifesto e aplique a versão modificada?