Por que o meu aplicativo recebe uma falha com um erro de ID de grupo para permissões de armazenamento de arquivo NFS?

Resolva falhas de permissão relacionadas ao ID do grupo de armazenamento de arquivos.

Infraestrutura clássica

Após você criar ou incluir armazenamento existente do NFS em seu cluster, a implementação do contêiner do seu app falha. Você vê mensagens de erro de ID do grupo (GID).

Ao criar um contêiner por meio de uma imagem que não especifica um usuário e ID do usuário (UID), todas as instruções no Dockerfile são executadas pelo usuário raiz (UID: 0) dentro do contêiner, por padrão.

No entanto, quando você desejar montar um compartilhamento de arquivo do NFS para seu contêiner, o ID do usuário 0 dentro do contêiner será mapeado para o ID do usuário nobody no sistema host NFS. Portanto, o caminho de montagem do volume é de propriedade do ID do usuário nobody e não do root. Esse recurso de segurança também é conhecido como root squash. O root squash protege os dados dentro do NFS montando o contêiner sem conceder as permissões raiz de ID do usuário no sistema de arquivos host NFS real.

Use um DaemonSet do Kubernetes para ativar a permissão raiz para o caminho de montagem do armazenamento em todos os nós do trabalhador para compartilhamentos de arquivos NFSv4.

Para permitir a permissão raiz no caminho de montagem do volume, deve-se configurar um configmap em seu nó do trabalhador. O configmap mapeia o ID do usuário nobody do sistema host NFS para o ID do usuário raiz 0 em seu contêiner. Esse processo também é referido como sem root squash. Uma maneira efetiva de atualizar todos os nós do trabalhador é usar um conjunto de daemon, que executa um pod especificado em cada nó do trabalhador no cluster. Neste caso, o pod que é controlado pelo conjunto de daemon atualiza cada um de seus nós do trabalhador para ativar a permissão raiz no caminho de montagem do volume.

A implementação é configurada para permitir que o pod de conjunto de daemon seja executado em modo privilegiado, o que é necessário para acessar o sistema de arquivos host. Executar um pod em modo privilegiado cria um risco de segurança. Portanto, use esta opção com cuidado.

Enquanto o conjunto de daemon estiver em execução, novos nós do trabalhador que são incluídos no cluster serão atualizados automaticamente.

Antes de Iniciar:

Conclua as etapas a seguir.

  1. Copie o arquivo YAML de implantação do conjunto de daemons norootsquash.

  2. Crie a implementação do conjunto de daemon norootsquash.

    oc apply -f norootsquash.yaml

  3. Obtenha o nome do pod para o qual seu volume de armazenamento está montado. Este pod não é o mesmo que os pods norootsquash.

    oc get pods

  4. Efetue login no pod.

    oc exec -it mypod /bin/bash

  5. Verifique se as permissões para o caminho de montagem são root.

    root@mypod:/# ls -al /mnt/myvol/
total 8
drwxr-xr-x 2 root root 4096 Feb  7 20:49 .
drwxr-xr-x 1 root root 4096 Feb 20 18:19 .

    Essa saída mostra que o UID na primeira linha agora pertence a root (em vez de nobody).

  6. Se o ID do usuário não for de propriedade de nobody, saia do pod e reinicialize os nós do trabalhador do cluster. Espere os nós serem reinicializados.

    ibmcloud oc worker reboot --cluster MY_CLUSTER --worker MY_WORKER1,MY_WORKER2

  7. Repita as Etapas 4 e 5 para verificar as permissões.