Como bloquear o UID/GID do contentor e a propriedade dos volumes antes das atualizações de aplicações autoalojadas

As atualizações de aplicações auto-hospedadas têm menos probabilidades de criar ficheiros pertencentes ao root quando a implementação fixa um contrato de utilizador numérico e valida a propriedade dos volumes antes de substituir o contentor.

A medida preventiva consiste em deixar de tratar o nome de utilizador interno da imagem como uma identidade de armazenamento estável. Registe o UID e o GID efetivos que escrevem dados persistentes, associe-os a diretórios do anfitrião ou a volumes nomeados, preserve quaisquer definições PUID/PGID ou de espaço de nomes de utilizadores e teste a nova imagem num pequeno caminho com permissões de escrita antes da implementação completa. Desta forma, uma atualização da imagem não pode alterar silenciosamente o proprietário numérico da configuração, dos carregamentos, das bases de dados ou dos metadados multimédia.

Registe o UID e o GID numéricos antes de atualizar

Registe o utilizador do processo em execução, o grupo primário, os grupos suplementares e a propriedade numérica de ficheiros representativos em cada montagem com permissões de escrita. Guarde o resumo de propriedade juntamente com o digest ou a versão da imagem.

As orientações da Docker para criação de imagens indicam que os IDs explícitos evitam divergências entre compilações, porque os utilizadores de imagens atribuídos automaticamente podem receber IDs numéricos diferentes entre compilações.

Registe números, não apenas nomes como app ou media. Uma nova imagem pode reutilizar o mesmo nome de utilizador e, ainda assim, alterar o respetivo UID, enquanto os ficheiros do anfitrião armazenam a propriedade numérica.

Fixe o utilizador de execução no contrato de implementação

Quando a imagem permitir a execução direta com uma conta sem privilégios de root, especifique explicitamente o utilizador e o grupo pretendidos no Compose ou na configuração de execução. Se a imagem exigir uma fase de inicialização com root, documente qual é o processo posterior que escreve efetivamente os dados persistentes.

A especificação de imagens Open Container define User como predefinição de execução, o que significa que uma imagem alterada pode modificar a identidade de execução, exceto se a implementação a substituir ou validar intencionalmente.

Não force um UID sem privilégios arbitrário em imagens que exijam um modelo de inicialização suportado. O contrato deve seguir o desenho documentado da aplicação, mantendo previsível o proprietário resultante dos ficheiros persistentes.

Mantenha o PUID e o PGID alinhados com a propriedade do anfitrião

Para imagens que disponibilizam variáveis PUID e PGID, fixe esses valores numa configuração Compose ou de ambiente sob controlo de versões e garanta que os diretórios dos volumes no anfitrião pertencem à conta de serviço correspondente.

A LinuxServer explica que o PUID associa as escritas do contentor, para que os ficheiros criados em volumes associados continuem a ser geríveis fora do contentor.

Antes de atualizar, compare os IDs configurados com o comando id no anfitrião e com a propriedade dos ficheiros existentes. Não copie cegamente um valor de exemplo, como 1000, para um servidor onde esse ID pertença a outra pessoa ou serviço.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Tenha em conta os espaços de nomes de utilizadores e o mapeamento sem root

O Docker ou Podman sem root pode fazer com que um processo pareça root dentro do contentor, embora seja associado a um UID sem privilégios no anfitrião. Registe o modo do espaço de nomes e a configuração de UID/GID subordinados antes de interpretar alterações de propriedade.

As opções de execução do Podman mostram que o keep-id preserva o mapeamento do utilizador quando um contentor precisa de acesso previsível a ficheiros montados a partir do anfitrião.

Não “corrija” um proprietário que pareça root dentro do contentor até inspecionar o ID numérico no anfitrião. O root associado a um espaço de nomes e o root do anfitrião nem sempre são a mesma identidade.

Teste previamente a nova imagem num volume de teste

Antes de substituir o contentor de produção, execute a nova imagem com o UID/GID pretendido e um diretório temporário que replique as permissões de produção. Permita que a inicialização crie um ficheiro e um diretório e, em seguida, inspecione a respetiva propriedade no anfitrião.

O guia de depuração de volumes sem root da Red Hat demonstra que a propriedade no anfitrião segue o mapeamento de UID, em vez de o nome de utilizador apresentado dentro do contentor ser, por si só, uma prova suficiente.

Se o teste criar ficheiros inesperadamente pertencentes ao root ou remapeados, interrompa a implementação e compare o utilizador da imagem, o ponto de entrada, o espaço de nomes e as definições de montagem. Isto é muito mais seguro do que descobrir a alteração depois de uma migração recursiva de arranque afetar uma árvore inteira de fotografias ou de uma base de dados.

Verifique os grupos suplementares e os caminhos com permissões de escrita

Algumas aplicações precisam de um UID de serviço primário, além de acesso através de um grupo partilhado de multimédia, transferências ou dispositivos. Registe esses IDs de grupo e teste todos os caminhos com permissões de escrita, não apenas o diretório de configuração.

O Kubernetes utiliza controlos runAsUser e runAsGroup explícitos, ilustrando o mesmo princípio de propriedade do Linux, mesmo fora de uma implementação Docker Compose simples.

A política de atualização está completa quando a nova imagem cria ficheiros com a propriedade esperada no anfitrião em todos os caminhos persistentes e sobrevive à recriação de um contentor. O artigo relacionado da ZimaSpace sobre ficheiros pertencentes ao root após atualizações de imagens é o ramo de recuperação caso uma implementação já tenha produzido dados pertencentes ao root.