A explicação técnica do que é contêiner não privilegiado é bastante boa. No entanto, não é para usuários comuns de PC. Existe uma resposta simples quando e por que as pessoas devem usar contêineres não privilegiados e quais são seus benefícios e desvantagens?
Respostas:
A execução de contêineres sem privilégios é a maneira mais segura de executar contêineres em um ambiente de produção. Os contêineres recebem publicidade ruim quando se trata de segurança e um dos motivos é que alguns usuários descobriram que, se um usuário obtém raiz em um contêiner, também existe a possibilidade de obter raiz no host. Basicamente, o que um contêiner não privilegiado faz é mascarar o ID do usuário do host. Com contêineres sem privilégios, usuários não raiz podem criar contêineres e terão e aparecerão no contêiner como raiz, mas aparecerão como ID do usuário 10000, por exemplo, no host (seja qual for o mapeamento dos IDs do usuário). Recentemente, escrevi um post sobre isso com base na série de blogs de Stephane Graber sobre LXC (um dos brilhantes desenvolvedores de mentes / líderes do LXC e alguém para seguir definitivamente). Eu digo novamente, extremamente brilhante.
Do meu blog:
Do contêiner:
lxc-attach -n ubuntu-unprived
root@ubuntu-unprived:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 04:48 ? 00:00:00 /sbin/init
root 157 1 0 04:48 ? 00:00:00 upstart-udev-bridge --daemon
root 189 1 0 04:48 ? 00:00:00 /lib/systemd/systemd-udevd --daemon
root 244 1 0 04:48 ? 00:00:00 dhclient -1 -v -pf /run/dhclient.eth0.pid
syslog 290 1 0 04:48 ? 00:00:00 rsyslogd
root 343 1 0 04:48 tty4 00:00:00 /sbin/getty -8 38400 tty4
root 345 1 0 04:48 tty2 00:00:00 /sbin/getty -8 38400 tty2
root 346 1 0 04:48 tty3 00:00:00 /sbin/getty -8 38400 tty3
root 359 1 0 04:48 ? 00:00:00 cron
root 386 1 0 04:48 console 00:00:00 /sbin/getty -8 38400 console
root 389 1 0 04:48 tty1 00:00:00 /sbin/getty -8 38400 tty1
root 408 1 0 04:48 ? 00:00:00 upstart-socket-bridge --daemon
root 409 1 0 04:48 ? 00:00:00 upstart-file-bridge --daemon
root 431 0 0 05:06 ? 00:00:00 /bin/bash
root 434 431 0 05:06 ? 00:00:00 ps -ef
Do host:
lxc-info -Ssip --name ubuntu-unprived
State: RUNNING
PID: 3104
IP: 10.1.0.107
CPU use: 2.27 seconds
BlkIO use: 680.00 KiB
Memory use: 7.24 MiB
Link: vethJ1Y7TG
TX bytes: 7.30 KiB
RX bytes: 46.21 KiB
Total bytes: 53.51 KiB
ps -ef | grep 3104
100000 3104 3067 0 Nov11 ? 00:00:00 /sbin/init
100000 3330 3104 0 Nov11 ? 00:00:00 upstart-udev-bridge --daemon
100000 3362 3104 0 Nov11 ? 00:00:00 /lib/systemd/systemd-udevd --daemon
100000 3417 3104 0 Nov11 ? 00:00:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
100102 3463 3104 0 Nov11 ? 00:00:00 rsyslogd
100000 3516 3104 0 Nov11 pts/8 00:00:00 /sbin/getty -8 38400 tty4
100000 3518 3104 0 Nov11 pts/6 00:00:00 /sbin/getty -8 38400 tty2
100000 3519 3104 0 Nov11 pts/7 00:00:00 /sbin/getty -8 38400 tty3
100000 3532 3104 0 Nov11 ? 00:00:00 cron
100000 3559 3104 0 Nov11 pts/9 00:00:00 /sbin/getty -8 38400 console
100000 3562 3104 0 Nov11 pts/5 00:00:00 /sbin/getty -8 38400 tty1
100000 3581 3104 0 Nov11 ? 00:00:00 upstart-socket-bridge --daemon
100000 3582 3104 0 Nov11 ? 00:00:00 upstart-file-bridge --daemon
lxc 3780 1518 0 00:10 pts/4 00:00:00 grep --color=auto 3104
Como você pode ver, os processos estão sendo executados dentro do contêiner como raiz, mas não aparecem como raiz, mas como 100000 do host.
Para resumir: Benefícios - segurança adicional e isolamento adicional para segurança. Desvantagem - Um pouco confuso para envolver sua cabeça primeiro e não para o usuário iniciante.
São ferramentas muito valiosas para testes, sandboxing e encapsulamento. Deseja que um servidor da Web seja bloqueado com segurança em seu próprio ambiente de trabalho, incapaz de acessar arquivos privados sensíveis? Use um recipiente. Você tem um aplicativo que requer versões antigas de bibliotecas e arquivos de configuração específicos, incompatíveis com outros aplicativos? Também um contêiner. É basicamente chroot feito da maneira certa. Ele permite que você mantenha os serviços separados o suficiente para manter cada um deles muito mais fácil, e eles podem ser movidos ou copiados para outra máquina sem precisar perturbar o sistema existente.
A desvantagem é que você precisa se lembrar do espaço para nome, pois quase tudo é local no contêiner. Você deve estar ciente de onde está e a comunicação entre os contêineres não é trivial. É uma boa ideia quando você precisa de modularidade, mas não deseja a sobrecarga das máquinas virtuais, e as coisas que você mantém nos contêineres não são muito relacionadas.
Para um usuário "comum", você pode usar contêineres para usar uma única máquina para duas pessoas, mantendo-os como se estivessem em máquinas completamente diferentes. Colegas de quarto, por exemplo.
Bem, com um kernel compartilhado, apesar de aumentar os requisitos do adversário para se libertar de algumas maneiras (ou melhor; ajuda a limitar a superfície de ataque), contêineres sem privilégios ainda não são completamente isolados de hacks diretos que ganham raiz do host, apesar disso .
Por esse motivo, é um pouco de suposição / reivindicação errada. Dito isto, o nível de aptidão técnica em muitos usuários da Internet ainda executará serviços inet, de várias maneiras das quais eles não são realmente tecnicamente capazes, então, ei. :)