新しいコンテナを起動するときに、Docker がデフォルトで同じユーザーと cgroup の名前空間を使用するのはなぜですか?
rootDocker が新しいユーザー名前空間を設定せず、コンテナ内がrootホストと同じにならない理由がわかりません。
特に、他のすべては名前空間化されているため (cgroup を除く)、デフォルトでコンテナを完全に分離しないことは実際には意味がありません。
ユーザー名前空間が Docker によってデフォルトで有効になっていない理由を誰か説明してもらえますか?
ホスト名前空間:
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]
コンテナ名前空間:
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]'
および名前空間userはcgroupホストとコンテナで同じです。
答え1
Docker がデフォルトでユーザーを有効にしないという決定の詳細については、おそらく Docker に問い合わせる必要があるでしょうが、考えられる理由を 1 つ挙げることはできます。
Docker の一般的な設計哲学は、開発ワークフローの中断や複雑さを最小限に抑えながらコンテナの使用を可能にすることであったようです。
ユーザー名前空間を有効にすると、コンテナーで使用されている uid/gid にマウントされたディレクトリに対する権限がない可能性があるため、基盤となるホストからボリュームをマウントするときにファイル/ディレクトリのアクセス許可に問題が発生する可能性があります。
もちろん、これらの権限を慎重に管理することで対処できますが、混乱が生じます。
ユーザー名前空間はオプションとして利用できるため、個々の組織やユーザーがそれを有効にすることは可能ですが、設定が必要です。
Dockerは「ルートレス」Dockerサポートを有効にすることにも取り組んでおり、これは現在実験的なオプションとして利用可能であることは注目に値します（詳細ここ) これにより、コンテナ (またはデーモン自体) が root として実行されないようにすることで、全体的な問題に対処できます。
答え2
これは基本的に、使いやすさとセキュリティの典型的なトレードオフです。私は開発者用デスクトップ用にこれを設定しました。CVE-2019-5736ユーザー名前空間によって軽減されると報告され、数か月後に無効にされました。これにより、ホストボリュームの操作が非常に困難になります。これは、デプロイされたクラウドネイティブアプリケーションにとっては大した問題ではありませんが、CIビルドやシステム管理ツールなどのDevOps目的でDockerを使用する場合、または多くのホストファイルに依存するレガシーアプリの場合は大きな問題になります。
問題をさらに複雑にしたのは、問題を抱えているのが私だけだったという事実です。もちろん、あなたが提案するようにユーザー名前空間がデフォルトであれば、このような事態にはならないでしょうが、この機能は docker 1.10 まで利用できず、それまでにデフォルトを変更すると、既存のユーザーに多大な混乱を招いてしまうでしょう。