Por que o Docker usa os mesmos namespaces de usuário e cgroup por padrão, ao iniciar um novo contêiner?
Não entendo por que o Docker não configura um novo namespace de usuário, de modo que rootno contêiner não seja o mesmo que rootno host.
Em particular, como todo o resto tem namespace (exceto cgroup), realmente não faz sentido não isolar completamente o contêiner por padrão.
Alguém pode esclarecer por que os namespaces de usuário não são habilitados pelo Docker por padrão?
Espaços de nome de host:
parallels@debian-gnu-linux-vm:~$ ls -la /proc/self/ns
total 0
dr-x--x--x 2 parallels parallels 0 Jan 30 17:29 .
dr-xr-xr-x 9 parallels parallels 0 Jan 30 17:29 ..
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 mnt -> mnt:[4026531840]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 net -> net:[4026531957]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 pid -> pid:[4026531836]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 user -> user:[4026531837]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 uts -> uts:[4026531838]
Namespaces de contêiner:
docker run -ti --rm debian:latest
root@210189a7a164:/# ls -la /proc/self/ns
total 0
dr-x--x--x 2 root root 0 Jan 30 16:30 .
dr-xr-xr-x 9 root root 0 Jan 30 16:30 ..
lrwxrwxrwx 1 root root 0 Jan 30 16:30 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 ipc -> 'ipc:[4026532287]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 mnt -> 'mnt:[4026532285]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 net -> 'net:[4026532290]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 pid -> 'pid:[4026532288]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 uts -> 'uts:[4026532286]'
Os namespaces usere cgroupsão iguais para o host e o contêiner.
Responder1
Quanto aos detalhes da decisão do Docker de não habilitar usuários por padrão, você provavelmente precisará perguntar ao Docker, mas posso oferecer uma possível explicação.
A filosofia geral de design do Docker parece ter sido permitir o uso de contêineres e, ao mesmo tempo, minimizar interrupções e complicações no fluxo de trabalho de desenvolvimento.
A ativação de namespaces de usuário pode causar problemas com permissões de arquivo/diretório ao montar volumes do host subjacente, pois o uid/gid em uso no contêiner pode não ter direitos para diretórios montados.
Isto pode ser resolvido, claro, através de uma gestão cuidadosa dessas permissões, mas é uma perturbação.
O namespace de usuário está disponível como uma opção, portanto ainda é possível que organizações e usuários individuais o habilitem, bastando apenas ser configurado.
É importante notar que o Docker também está trabalhando para habilitar o suporte Docker "sem root" e isso está disponível como uma opção experimental agora (mais detalhesaqui) e isso resolveria o problema geral, garantindo que nenhum contêiner (ou o próprio daemon) seja executado como root.
Responder2
É basicamente a clássica troca entre usabilidade e segurança. Eu configurei-o para minha área de trabalho de desenvolvedor depoisCVE-2019-5736foi relatado como sendo mitigado por namespaces de usuários e foi desativado alguns meses depois. Isso torna muito difícil trabalhar com volumes de host. Isso não é grande coisa para um aplicativo nativo em nuvem implantado, mas é enorme se você usar o docker para fins de devops, como compilações de CI ou ferramentas de administração de sistemas, ou para aplicativos legados que dependem de muitos arquivos host.
Para agravar o problema, estava o fato de que eu era o único com o problema, o que obviamente não seria o caso se os namespaces de usuário fossem o padrão, como você sugere, mas o recurso não estava disponível até o docker 1.10 e então alterando o padrão teria sido muito perturbador para os usuários existentes.