Dockerはコンテナープロセスをrootとして実行します-心配する必要がありますか？
私は（QNAP）NAS Docker機能付き（ " containerstation "）を実行しています。ストア（またはサードパーティのストア）。
多くのパッケージは公式ストアでは古くなっており、QNAPはすべてのプログラムとアプリをroot/admin（ウェブサーバーを含む）として実行するため、Dockerが解決策になると思いました。
これで、いくつかのDockerインスタンスがデプロイされ、それらのプロセスはroot/adminとしても実行されているように見えます。
これは私を思い起こさせます。現時点で私が持っている誤った安心感はありますか？または、「通常の」ルートよりもはるかに安全なdockerコンテナーの使用ですか？
ルートとして実行されているコンテナ化されたアプリケーションについて心配していると思います。
コンテナ内のルートはリスクです。それはまだルートとしてカーネルと対話します。また、アプリケーションがコンテナから抜け出すことができた場合、そのアプリケーションにはホストに対するルート権限があります。
ただし、コンテナのルートには、ホストのルートと比較して capabilities が制限されています。例えば。 mountに必要な機能SYS_ADMINがありません。ただし、リスクを最小限に抑えるために、可能な場合は常にコンテナー内のルートを避けてください。
コンテナー化されたアプリケーションにroot特権が必要ない場合は、特権のないユーザーでコンテナーを実行できます。最も簡単な方法は、--user UID:GIDでオプションdocker runを指定することです。
ただし、コンテナ化されたアプリケーションにはroot権限が必要だと思います。 Dockerはこれに対処するためにuser namespacingを提供します。
ここでは、ユーザーの名前空間に慣れていないため、ここでは設定例を示しません。私はそれを一度セットアップし、それが動作することを確認できます。ドキュメントを読むことをお勧めします： https://docs.docker.com/engine/security/userns-remap/
略して、ユーザー名前空間のセットアップは、ホスト上で非特権ユーザーにマップされるコンテナー内の「偽の」ルートユーザーを実現します。アプリケーションが故障した場合、そのアプリケーションにはホストに対するroot権限がありません。
それとは別に、コンテナの機能を減らしてコンテナのセキュリティを向上させることができます。オプション--cap-drop=xyzを使用して、コンテナーに不要なものをすべてドロップします。または、--cap-drop=ALLを使用して、本当に必要な機能のみを追加します。 --cap-add=CHOWN。見てください https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
コンテナのセキュリティを向上させる別のオプションは、--security-opt=no-new-privilegesです。