O que é uma maneira prescritiva de gerenciar as permissões para volumes montados no Docker baseado em Alpine?

Question

Ao criar uma imagem, você pode atribuir a propriedade ( chown ) e alterar as permissões ( chmod ) dos caminhos na imagem. No entanto, quando um volume é montado a partir do host ou de outro contêiner, as permissões para esse volume estão presentes, possivelmente introduzindo um usuário / grupo desconhecido para o contêiner em que ele é montado.

Estou interessado em um método prescritivo (se houver) para lidar com permissões para usuários em uma imagem do Alpine Docker para volumes montados em contêiner e montados em contêiner.

As duas opções possíveis que consigo pensar são:

1. Use o mesmo usuário e grupo entre contêineres e volumes montados.
2. Use as ACLs para controlar as permissões.

Existe uma abordagem recomendada para abordar problemas de permissão para volumes montados, especialmente quando o uid / gid dos proprietários não corresponde aos usuários / grupos dentro de um contêiner? Por exemplo,

Dentro da minha imagem do Alpine Docker, meu usuário www-data tem um uid / gid de 82 (veja: id do usuário nginx www-data ), se eu montar um volume de outro container ou o host em que um usuário com o uid 1001 e gid 1001 possui o volume, como eu lido com a disparidade de propriedade e permissões?

NB: Algumas estruturas de aplicativos (por exemplo, Symfony ) recomendam o uso de algo como setfacl [1 ] para gerenciar permissões, mas isso não parece ser possível sob uma imagem do Alpine Docker com o AUFS porque a operação "não é suportada".

O uso de ACLs é um antipadrão no Docker?

    

Answer 1

NB: StackOverflow has the following question: What is the best way to manage permissions for docker shared volumes? which is similar to the above and numerous answers, with the prevailing answer being this one.

A partir da experimentação e da leitura de inúmeras fontes que procuram uma resposta prescritiva ou um padrão comum, identifiquei o seguinte:

Ao executar Docker-outside-of-Docker (DooD), os volumes de dados do host são montados a partir do host subjacente. Lembro-me de tropeçar em alguma menção a isso em um post, mas por toda a vida eu não consigo encontrar agora (Se / quando eu fizer, atualizarei esta resposta). O melhor e mais curto é o seguinte: quando você estiver executando o Docker por meio de um docker.sock compartilhado dentro de um contêiner, o Docker tentará montar volumes a partir do host subjacente . Se você montar volume (s) de outro container, você não tem esse problema.

Atribuir permissões e propriedade. O problema que observei acima (com setfacl não funcionando) parece ter sido um problema do usuário. Eu devo ter tentado executá-lo sob as permissões do usuário não-root ou em um diretório do qual meu usuário não possuía. Para contornar problemas de propriedade, você pode usar um script docker-entrypoint.sh que será chown ou setfacl como o usuário root antes de executar o comando como o usuário da imagem. Até o momento, identifiquei duas opções viáveis para lidar com problemas de propriedade e permissões:

• Use sudo para alterar a propriedade ou definir listas de controle de acesso.
• Permitir que o seu contêiner seja executado usando o usuário root e depois passar para outro usuário para executar o comando usando gosu ou su-exec .

Eu comecei a combinar as duas observações acima para minha abordagem auto-prescritiva, então ...

1. Sempre que montar um volume de host em um contêiner do Docker que também compartilhe o docker.sock com o host, é recomendável que os diretórios sejam correspondentes. Por exemplo, se o volume montado no Dockerfile for declarado como /var/data , monte /var/data do host (por exemplo, -v /var/data:/var/data ). Isso é especialmente se você tiver arquivos ou diretórios em /var/data que deseje montar a partir do contêiner em um novo contêiner.
2. Seja proativo em relação às permissões, sempre inclua um arquivo docker-entrypoint.sh que, no mínimo, atualiza a propriedade ou o controle de acesso para um diretório montado.