Lista de verificação do mapeamento de utilizadores e grupos de contentores para partilhas NAS

A abordagem segura consiste em tratar uma verificação do mapeamento de identidades numéricas, desde a exportação do NAS, passando pela montagem no anfitrião, até ao processo do contentor em execução, como uma sequência de etapas observáveis, e não como um único comando.

Num anfitrião de contentores Linux que utilize partilhas NAS suportadas por SMB ou NFS, o risco prático é um contentor conseguir ver um caminho montado a partir do NAS, mas as leituras ou escritas falharem com erros de permissões. Registe a identidade atual e o ponto de recuperação, comece pelo teste discriminador menos invasivo, interprete os resultados positivos e negativos antes de alterar outra variável e pare quando o armazenamento ficar instável ou quando a única cópia recuperável ficar exposta. O fluxo de trabalho abaixo só termina quando a carga de trabalho original for bem-sucedida ou quando as evidências atingirem um limite de escalada.

Identificar a identidade real do processo do contentor

Consulte a documentação da imagem, a definição user do Compose, as variáveis de ambiente, o comportamento do entrypoint e o UID, GID e grupos suplementares do processo da aplicação em execução. As variáveis com os nomes PUID e PGID são convenções das imagens, não funcionalidades universais do Docker, por isso confirme se esta imagem as suporta.

Um caso da comunidade LinuxServer sobre um caso de permissões de PUID e PGID num contentor demonstra que valores de PUID e PGID aparentemente corretos podem, ainda assim, deixar uma montagem de ligação inacessível. Use o caso como lembrete para inspecionar o processo e a montagem em execução, não como prova de que todas as imagens implementam a mesma lógica de inicialização.

Registe os valores numéricos com id dentro do contentor e no anfitrião. Pare se a aplicação só for executada como root porque as permissões falharam anteriormente; o acesso de root oculta o defeito de mapeamento e aumenta o impacto de um serviço comprometido.

Rastrear a propriedade desde o NAS até à montagem no anfitrião

No NAS, inspecione o proprietário numérico, o grupo, o modo, a ACL e a ACL predefinida do diretório de destino. No anfitrião do contentor, inspecione os mesmos objetos montados e compare os valores numéricos. Se os nomes forem diferentes mas os números coincidirem, os rótulos são meramente cosméticos; se os números forem diferentes, o caminho de autorização é realmente diferente.

Para NFS, inclua as opções de exportação, a versão do NFS, o mapeamento de identidades, o root squashing e a identidade da montagem do cliente. Para SMB, inclua as credenciais de montagem, a identidade mapeada no servidor, as opções de apresentação uid ou gid e se estão a ser utilizadas extensões Unix ou tradução de ACLs.

Não altere simultaneamente as ACLs do servidor e as opções de montagem do cliente. A etapa é bem-sucedida quando um ficheiro de teste tem um proprietário numérico conhecido e o anfitrião apresenta um mapeamento estável após desmontar, voltar a montar e reiniciar.

Testar a montagem de ligação e os grupos suplementares

Confirme que o caminho de origem do contentor corresponde à montagem esperada no anfitrião, e não a um diretório local vazio criado antes de a partilha de rede ser montada. Inspecione a montagem em execução e, em seguida, teste a listagem, leitura, criação, mudança de nome e eliminação como o utilizador da aplicação, dentro de um subdiretório descartável.

Um caso do Server Fault documenta uma incompatibilidade de permissões de ACL no NFS mesmo quando as entradas do proprietário e da ACL parecem estar alinhadas, ilustrando por que motivo é necessário inspecionar a máscara da ACL, o mapeamento do servidor e a identidade efetiva. Recolha o resultado de getfacl tanto no diretório como no ficheiro criado.

Se o acesso através de grupos for intencional, adicione o grupo numérico suplementar suportado e recrie o contentor, porque os grupos do processo são fixados no arranque. Utilize o guia da ZimaSpace sobre diagnóstico de caminhos vazios em contentores quando a aplicação é iniciada com um caminho vazio; trata-se de um problema de ordem de montagem, não de um problema de ACL.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Aplicar a correção de identidade mais restrita e testar novamente

Prefira alinhar o UID, GID ou grupo suplementar suportado pela aplicação com a política do NAS. Utilize um grupo partilhado e uma ACL herdada quando vários serviços colaborarem. Evite permissões de escrita para todos, alterações recursivas de propriedade em conjuntos de dados não relacionados e contentores privilegiados como atalhos.

Recrie o contentor, volte a montar a partilha se as opções de mapeamento tiverem sido alteradas e repita as mesmas operações. Reinicie o anfitrião uma vez para verificar se a ordem de montagem e a identidade numérica se mantêm após o arranque. Confirme que os ficheiros criados continuam a poder ser escritos pelos clientes humanos pretendidos, sem conceder direitos desnecessários ao contentor.

Feche a lista de verificação quando a aplicação passar a sua carga de trabalho original, as operações negadas continuarem negadas e a propriedade permanecer estável após o reinício. Escale o problema se os espaços de nomes de utilizadores, os mapeamentos sem root ou os serviços de identidade do NAS reescreverem os IDs de uma forma que a imagem escolhida não consiga suportar.