非特権コンテナとは の技術的な説明はかなり良いです。ただし、一般のPCユーザー向けではありません。特権のないコンテナをいつ、なぜ使用する必要があるのか、簡単な答えはありますか。また、それらの利点と欠点は何ですか?
非特権コンテナーの実行は、実稼働環境でコンテナーを実行する最も安全な方法です。セキュリティに関してはコンテナーの評判が悪くなり、その理由の1つは、ユーザーがコンテナーのルートを取得すると、ホストでもルートを取得する可能性があることを発見したユーザーがいるためです。基本的に、非特権コンテナが行うことは、ホストからユーザーIDをマスクすることです。非特権コンテナーでは、非rootユーザーはコンテナーを作成でき、コンテナーとしてrootとして保持および表示されますが、例えばホストではユーザーID 10000として表示されます(ユーザーIDをマップするものは何でも)。私は最近、LXCの Stephane Graberのブログ シリーズに基づいて、これに関するブログ投稿を書きました(LXCの優秀なマインド/リード開発者の1人であり、確実にフォローしてください)。もう一度言いますが、非常に素晴らしいです。
私のブログから:
コンテナから:
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
ご覧のように、プロセスはコンテナー内でrootとして実行されていますが、rootとしてではなくホストから100000として表示されています。
まとめると、メリット-セキュリティの追加とセキュリティの分離の追加。欠点-初心者向けではなく、最初に頭を回すのが少し混乱します。
これらは、テスト、サンドボックス化、およびカプセル化のための非常に貴重なツールです。機密性の高いプライベートファイルにアクセスできない、Webサーバーを独自の作業環境で安全にロックしたいですか?コンテナを使用してください。他のアプリケーションと互換性のない、古いバージョンのライブラリと特定の構成ファイルを必要とするアプリケーションがありますか?コンテナも。基本的にはchrootが正しく行われています。これにより、サービスを十分に分離して維持できるため、各サービスの維持がはるかに簡単になり、既存のシステムに影響を与えることなく、サービスを別のマシンに移動またはコピーできます。
欠点は、ほとんどすべての名前空間をコンテナにローカルであることを覚えておく必要があることです。あなたは自分がどこにいるかを意識する必要があり、コンテナー間の通信は簡単ではありません。モジュール性が必要な場合に適していますが、仮想マシンのオーバーヘッドは必要ありません。また、コンテナーに保持するものはあまり関係ありません。
「通常の」ユーザーの場合、コンテナーを使用して、1人のマシンを2人で使用し、まったく別のマシンにいるかのように保つことができます。たとえばルームメイト。
まあ、共有カーネルを使用すると、何らかの方法で解放するという敵の要件が高まっているにもかかわらず(または、攻撃面を制限するのに役立ちます)、非特権コンテナは、これにもかかわらず、ホストルートを取得する単純なハックから完全に分離されていません。
そのため、それは少し間違った仮定/主張です。そうは言っても、インターネット上の多くのユーザーの技術的適性のレベルは、実際には技術的にはできない多くの方法で、inetサービスを実行します。 :)