rootとして実行されるdockerデーモンによってもたらされるリスク
私のチームは、Dockerを使用することに非常に興奮しています。これは、Dockerが展開を簡素化し、他の多くの設計および運用上の利点を提供することを約束しているためです。私たちは最近、それで本当に物事を動かし始め、Dockerデーモンがrootとして実行されるという事実でいくつかの問題に遭遇しました。
一般に、ルートとしてサーバープラットフォームを実行する私のスタンスは「しない」です。最近、私たちはオペレーターにこれをやめるように、そしてサーバーの展開を変更する可能性のあるアカウントでの実行を停止するために、たくさんの戦いを経験しました。そのため、すぐに、これらの同じユーザーに戻って、Dockerをrootとして実行するようにセットアップするよう依頼することは少し偽善的であるように見えるという問題があります。
ルートとして実行されているdockerデーモンによって提示された risks についてコメントするのは私が最初ではありません。 this によると、「最終的には、Dockerデーモンが制限された権限を実行することが予想されます...」これが対処されるのを待つだけでいいですか？ dockerはセキュリティプロファイルを改善するだろうと思っていましたが、これはそれをさらに悪化させるようです。私の熱意はドッカーに対してしぼんでおり、私がリスクチームにこの状態でそれを使用するための主張をする意欲があるかどうかはわかりません。
編集：ここでは、ユーザーが「ドッカー」グループのメンバーであることをめぐる問題に特に関心がないことを明確にすべきです。知ることは重要ですが、それは管理することができます。私はここですべての素晴らしい答え（プロとコンの両方）に本当に感謝しています。私はデーモンをコンテナ自体と融合させてきたと思います。おそらく、Dockerアーキテクチャの明確なメンタルモデルに取り組む必要があります。繰り返しになりますが、ここにはたくさんの素晴らしいものがあります。答えを受け入れる前に少し反省する必要があります。
これがドッカーの大きな欠陥だと思うのは間違っていますか？
Dockerデーモンは、ほとんど基本的な方法でホストオペレーティングシステムとインターフェイスするため、rootとして実行されますが、その特権を必要とするLinux機能を利用するほとんどのシステムデーモンと同じです。
これは、Dockerの使用が安全でないことを意味するのではなく、Dockerの使用方法に注意する必要があるだけです。幸いなことに、これについて Docker自体 から、そして Center for Internet Security からセキュリティ構成の「ベストプラクティス」ガイドの形で入手できるかなり良いセキュリティ構成アドバイスがすでにいくつかあります。
Dockerを実行するときに注意する必要がある実際的な考慮事項がいくつかあります。
まず、誰かがホストの「docker」グループのメンバーである場合、この場合はdockerを使用して特権を昇格させることができるため、システムのルートになります。したがって、本番ホスト上のそのグループのメンバーシップを慎重に扱う必要があります。
DockerはLinux機能を使用して、コンテナー内のユーザーが実行できるアクションを制限します。そのため、コンテナー内でrootになるだけでは、必ずしもホスト上で自動的にrootになるわけではありません。とはいえ、ボリュームマウントなどに注意する必要があります（システムディレクトリをホストからコンテナーにマウントする場合など）。これにより、コンテナー内のrootユーザーがホスト上のファイルを変更できるようになる可能性があります。
コンテナーに提供される機能をかなり簡単に減らすこともできます。これにより、プロセスのセキュリティをさらに向上させることができます。
また、コンテナーでプロセスをrootとして実行する必要はなく、わずかな構成で他のユーザーとして実行できます。これにより、ボリュームのマウントのリスクが軽減されます。
コンテナーについて考える方法は、ホスト上のプロセスであることがわかりました。コンテナーでの実行をホストで直接実行する場合と比較すると、コンテナーアーキテクチャではプロセスを削除するのではなくセキュリティを追加する可能性が高いと言えます。これは、プロセスとホストの間のインターフェイスがより明確に定義されているためです。ホスト上でプロセスが実行できることを制御します。
また、よりリッチなユーザーマッピングアーキテクチャが間もなくDocker（ 1.9で予定 ）に登場し、コンテナー内のアクションを制限するためのオプションがさらに追加されることは何の価値もありません。
いいえ、違います。
または、別の言い方をすれば、心配するのを誤ると、同様に誤解しているセキュリティ専門家がたくさんいます。いくつかの顕著な例を挙げましょう。
-専門家がインタビュー ここ Dockerセキュリティ、特にデーモンルートの問題について。 CERTの男性を含める：
はい、そうです。Dockerや他の多くのコンテナテクノロジーは、その魔法を実行するためにルートアクセスを必要とします。そして、ルートアクセスを必要とする他のプログラムと同様に、大きな力には、大混乱をもたらす大きな機会があります。
カーネギーメロン大学のCERTの研究者であるアーロンコイスが最近DevOpsの出版物に語ったところ、「Dockerで私が目にする最大の脅威の1つは、その位置付けと言語の暗黙のセキュリティです。実際、これらのコンテナーには何も含まれていません。 」確かにそうです。
また、コンテナー内でroot権限で何かを実行すると明らかに問題があります。「コンテナー内でroot（UID 0）として実行されているプロセスは、カーネルと対話するときに、基盤となるホストでrootレベルの権限を持っています。」
この記事では、特にデーモンのルートステータスに関連する問題の詳細と、Docker全体で少し気になるセキュリティ問題の概要について説明しています。
- こちら Dockerに関する多くのセキュリティ問題について話しているチームからの非常に優れた分析です。これには、ルートとしてのデーモンに直接関連するものや、それらとの闘い/軽減方法が含まれます。ここのプレゼンターは、一般的にDockerのセキュリティについて混合的からある程度ポジティブな見解を提供しますが、セットアップを作成するときに頭に浮かぶ必要がある可能性のある脅威ベクトルがいくつかあることを明らかにします。
要点はわかると思います。 （Googleはそれらのポイントを明確に表現するより多くの部分を明らかにしています、そして私は個人的に過去数年にわたってあちこちでいくつか他のものを読んだことがあります。）今、私はDockerを想像の範囲で打ちのめしていません。 deamon-as-rootを含め、Dockerの堅固ではないセキュリティアーキテクチャが存在することを可能にする脅威を大幅に減らすことができるものを慎重にセットアップして維持する方法。 （そして、確かにコンテナーは簡単で使いやすいです。）しかし、あなたは間違いなくwrongではなく、Dockerについて懸念を抱いていますnot合理的で最大限の特権削減を含む、最新の優れたアプローチを使用します（少なくともDockerは現在のところです）。
RHEL DockerイネーブルメントチームのリーダーであるDaniel Walshからの記事（Dockerと戦う理由がない人）についてDockerセキュリティも興味深いものです。重要な考えの1つは、「コンテナ内で実行されている特権プロセスがコンテナ外で実行されている特権プロセスと同じであると仮定するだけです。」。
これは比較的古い記事、2014年7月です。Linuxコンテナー（Dockerに依存）が進化し、2014年1月に非特権コンテナーが導入され、コンテナー内の特権プロセスがホストシステムポイントからエンドユーザー特権で実行されるようになりました。 -見る。
ただし、この機能はDockerではまだサポートされておらず、何度か延期されました。
別の答え Dockerセキュリティに関する 私は、セキュリティの問題のためにDockerを離れる前にDockerに依存していた他のいくつかのセキュリティ指向プロジェクトについても触れました。
だから、あなたが言ったように、Dockerは「配備を簡素化し、他の多くの設計と運用上の利点を提供することを約束します」、これは確かに真実であり、はDockerの主な目標ですが、Daniel Walshが強調したように、分離によるセキュリティはこれらの約束の一部ではありません。
多くの場合、セキュリティと機能の間には妥協点があります。 Dockerは、はしごの機能面に位置しているようです。 Docker機能によって付加された価値に価値があるかどうかは、あなた次第です。