비특권 컨테이너의 장점과 단점은 무엇입니까?

권한이 없는 컨테이너를 실행하는 것은 프로덕션 환경에서 컨테이너를 실행하는 가장 안전한 방법입니다. 컨테이너는 보안과 관련하여 나쁜 평가를 받고 있으며, 그 이유 중 하나는 사용자가 컨테이너에서 루트 권한을 얻으면 호스트에서도 루트 권한을 얻을 수 있다는 사실을 일부 사용자가 발견했기 때문입니다. 기본적으로 권한이 없는 컨테이너가 수행하는 작업은 호스트에서 사용자 ID를 마스크하는 것입니다. 권한이 없는 컨테이너의 경우 루트가 아닌 사용자는 컨테이너를 생성할 수 있으며 컨테이너에서는 루트로 표시되지만 호스트에서는 사용자 ID를 매핑하는 대상에 관계없이 사용자 ID 10000으로 표시됩니다. 나는 최근에 이것에 관해 블로그 게시물을 썼습니다.스티븐 그레이버의 블로그LXC 시리즈(LXC의 뛰어난 인재/선두 개발자 중 하나이며 확실히 주목해야 할 시리즈). 반복합니다. 훌륭합니다.

내 블로그에서:

컨테이너에서:

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

호스트로부터:

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

보시다시피 프로세스는 컨테이너 내에서 루트로 실행 중이지만 루트로 표시되는 대신 호스트 시스템에서는 100000으로 표시됩니다.

요약하면 다음과 같습니다. 이점 - 보안 강화 및 보안 격리 강화. 단점 - 처음에는 약간 혼란스러워서 초보 사용자에게는 적합하지 않습니다.

이는 매우 귀중한 테스트, 샌드박싱 및 패키징 도구입니다. 민감한 개인 파일에 접근하지 않고도 작업 환경에서 웹 서버를 안전하게 잠그고 싶으십니까? 용기를 사용하세요. 귀하의 애플리케이션에는 이전 버전의 라이브러리와 다른 애플리케이션과 호환되지 않는 특정 구성 파일이 필요합니까? 또한 컨테이너. 기본적으로 chroot가 완료되었습니다. 이를 통해 서비스를 독립적으로 유지 관리할 수 있으므로 각 서비스를 더욱 쉽게 유지 관리할 수 있으며 기존 시스템을 방해하지 않고 서비스를 다른 컴퓨터로 이동하거나 복사할 수 있습니다.

단점은 거의 모든 것이 컨테이너에 로컬이므로 네임스페이스를 기억해야 한다는 것입니다. 자신이 어디에 있는지 알아야 하고, 컨테이너 간 통신도 만만치 않습니다. 이는 모듈성이 필요하지만 가상 머신의 오버헤드를 원하지 않고 컨테이너에 저장하는 내용이 그다지 중요하지 않은 경우에 좋은 아이디어입니다.

"일반" 사용자의 경우 컨테이너를 사용하여 두 사람이 하나의 시스템을 사용하면서 완전히 다른 시스템에 있는 것처럼 작동하도록 할 수 있습니다. 예를 들어 룸메이트를 생각해 보세요.

공유 커널을 사용하면 공격자가 어떤 방식으로든(또는 오히려 공격 표면을 제한하는 데 도움이 됨) 해제해야 하는 요구 사항이 높아지지만 권한이 없는 컨테이너는 여전히 호스트의 루트를 얻는 직접 해커와 완전히 비교할 수는 없습니다. 하지만 격리.

따라서 이것은 약간 잘못된 가정/주장입니다. 그렇긴 하지만, 인터넷의 많은 사용자는 여전히 inet 서비스를 실행할 수 있는 기술적 능력 수준에 있지만 실제로는 여러 가지 방법으로 이를 실행할 수 있는 기술적 능력이 없습니다. :)