특권 컨테이너 가 무엇인지에 대한 기술적 설명 은 꽤 좋습니다. 그러나 일반 PC 사용자는 아닙니다. 사람들이 권한이없는 컨테이너를 사용해야하는시기와 이유에 대한 간단한 대답이 있습니까? 그리고 장점과 단점은 무엇입니까?
답변
권한없는 컨테이너를 실행하는 것이 프로덕션 환경에서 컨테이너를 실행하는 가장 안전한 방법입니다. 컨테이너는 보안에 관해 나쁜 평판을 얻습니다. 그 이유 중 하나는 일부 사용자가 사용자가 컨테이너에서 루트를 얻는 경우 호스트에서도 루트를 얻을 가능성이 있다는 것을 발견했기 때문입니다. 기본적으로 권한이없는 컨테이너가하는 일은 호스트에서 사용자 ID를 마스킹하는 것입니다. 권한이없는 컨테이너를 사용하면 루트가 아닌 사용자는 컨테이너를 작성할 수 있으며 컨테이너에 루트로 표시하고 컨테이너에 표시하지만 호스트와 같이 사용자 ID 10000으로 표시됩니다 (사용자 ID를 맵핑 한대로). 필자는 최근 LXC 에 관한 Stephane Graber의 블로그 시리즈 (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 서비스를 계속 실행할 수 있습니다. 🙂