Dockerコンテナを信頼しても安全ですか？
Dockerに関しては、既存のサードパーティのコンテナーを使用して、目的の処理を行うのが非常に便利です。問題は、それらのコンテナーが非常に複雑になり、他のコンテナーの親ツリーが大きくなる可能性があることです。 GitHubなどのリポジトリからコードをプルすることもできます。このすべてがセキュリティ監査を難しくしています。
単純に聞こえるかもしれませんが、誰かが悪意のあるコンテンツをコンテナに隠すのは簡単でしょうか？私は答えがYESであることを知っていますが、どの次元で、それがリスクに値するかどうか知りたいのです。私はGitHubに精通しており、サードパーティのコードを使用するときは、よくソースコードを調べます（よく知られたプロジェクトでない限り）。
悪意のあるコンテナの害は悪意のあるコードよりも大きい可能性があるため、コミュニティがこのような種類の動作を監視しているかどうか疑問に思っています。
コンテナーが悪意のある可能性はどれくらいですか？ （人気のあるものと考えてください。）同様に、下線システムの他のコンポーネントまたはLAN上の他のシステムを損傷/使用する可能性のある寸法はどれですか。もっと簡単にするために、私はそれらを信頼するべきですか？
編集：Dockerのセキュリティとベストプラクティスに少し光を当てるDockerの記事を見つけました： Dockerのセキュリティとベストプラクティスについて 。
現時点では、特定のDockerコンテナーを信頼するかどうかを簡単に判断する方法はありません。 DockerおよびOSプロバイダーによって提供される基本コンテナーがあり、それらは「信頼された」と呼ばれますが、ソフトウェアにはまだ画像が改ざんされていないことを確認するための優れたメカニズム（デジタル署名など）がありません。
明確化のために、最近リリースされた dockerのCISセキュリティ標準 セクション4.2
公式リポジトリは、Dockerコミュニティまたはベンダーによってキュレートおよび最適化されたDockerイメージです。ただし、Dockerコンテナーイメージの署名と検証機能はまだ準備されていません。
したがって、Dockerエンジンは、コンテナーイメージの出所だけを検証しません。
したがって、コンテナイメージを取得するときは、十分な注意が必要です。
Dockerハブから一般的なサードパーティコンテナーの世界に入ると、状況はさらに複雑になります。 AFAIK docker dono他の人のコンテナファイルのチェックを行うので、いくつかの潜在的な問題があります
- コンテナには実際のマルウェアが含まれています。これはありそうか、誰にもわからない。はい、可能です。
- コンテナに安全でないソフトウェアが含まれています。 Dockerfileは基本的に、マシンを構築するバッチスクリプトのようなものです。暗号化されていないHTTP接続を介してファイルをダウンロードし、それらをコンテナーのルートとして実行するようなものをいくつか見ました。私にとって、これは安全なコンテナを取得する良い方法ではありません
- コンテナが安全でない設定を設定しています。 Dockerは、ソフトウェアのセットアップを自動化することを目的としています。つまり、Dockerfileを作成したすべての人々が、それらを好きなように安全に構成することをある程度信頼しています。
もちろん、すべてのdockerfilesを監査することもできますが、それが完了したら、自分で構成するだけでほとんど改善されます。
これが「リスクを負う価値がある」かどうかについては、それはあなただけが本当にできる決定だと思います。ダウンロードしたソフトウェアの作成に関与した誰かが悪意のある、またはシステムのセキュリティに関して誤りを犯したというリスクの増大に対して、自分のイメージを開発および維持するために必要な時間をトレードオフしています。
システムで実行する署名されていないコードと同じくらい信頼してください。コンテナーは、いくつかの追加の名前空間保護を備えたプロセスにすぎないので、コンテナーが得るすべての保護です。彼らはまだ同じカーネルと対話します。
Dockerコンテナは、ホストシステムでアプリケーションを実行するのと同じものと考えるのが最善です。 Linuxカーネル機能を削除してDockerデーモンをロックダウンする試みがいくつかありますが、これは実際には保証されていません。 Dockerを実行する場合、このリスクの一部を軽減するためにできることがいくつかあります。
- SELinux-これを有効にすると、各コンテナーのMCSラベルが自動的に生成され、損傷を与える能力が制限されます。
- 読み取り専用-コンテナーのイメージの大部分を読み取り専用にして、コンテナーを読み取り専用にすることもできます。攻撃者がマルウェアを展開するのは困難です。
- 自己ホスト型レジストリ-イメージの改ざん、悪意のあるコンテナの読み込み、シークレットの漏えいなどのリスクを軽減するために、内部でレジストリをホストできます。 。 https://github.com/dogestry/dogestry はS3の上にある例ですが、他のオプションもあります。
本質的には、オープンソースソフトウェアが信頼できるかどうかと同じ問題だと私は主張します。しかし、コミュニティのDockerコンテナーを使用するリスクは、オープンソースソフトウェアを使用するリスクよりも、現在少し高いと思います。
最初に、あなたが述べたように、署名と検証は現在ありません。 今日の優れたオープンソースパッケージシステムにはこれが含まれます 、少なくとも公式リポジトリからソフトウェアを取得する場合。また、1回限りのプロジェクトでも、ダウンロードバンドルにチェックサムが含まれる傾向があります。したがって、オープンソースの世界では、コードが安全かどうかはわかりませんが、多くの場合、必要なコードを取得していることがわかります。 Dockerを使用すると、コンテナーの公開とダウンロードの間にコンテナーが変更されないことさえわかりません。
2つ目は、パッケージ自体の問題です。あなたの活動をインターネットの目的地に報告するなど、ソフトウェアが何か厄介なことをしていないのですか？これは かつてオープンソースソフトウェアに対する一般的な恐れでした です。今日、多くの大企業は、オープンソースソフトウェアを組み込んだ技術的な実装者に疑問を投げかけていません。おそらく、このように クローズドソースソフトウェアはさらに悪くなる可能性があります 。しかし、Dockerコンテナの場合、特にオペレーティングシステムのツールとライブラリのフルセットが含まれている場合、「攻撃対象」は非常に大きくなります。 postfixの悪いビルドを使用していると思われる場合は、公式のコードを入手してビルドしてください（一部のパッケージマネージャーは通常これを行います）。 Dockerコンテナに問題があると思われる場合、イメージを「ソースから」複製するのは、ちょっとした冒険です。
SECURITY Dockerコンテナーを信頼できますか？これに対する答えはほとんど常にノーだと思います！
私の場合、「linuxserver/openvpn-as」について疑問に思っています。ああ、それを私のdocker swarmsの1つにポップし、それを私のプライベートネットワークに開いて、それらのネットワークへのリモートユーザーアクセスを管理させるのはいいことではないでしょうか。しかし、出所のないWebから降りたコンテナにこのようなものをどのように信頼できますか？それがなければ、私はできないと思います。
私が来歴を持っているなら、私は作成者を信頼する必要があります
- 同じように信頼できるものから始めた（など）
- 悪意のあることをしていない、そして
- インストールまたは構成の手順で安全でない選択を行わなかった。
これは、それ自体、かなり大きな注文です。この場合、私はlinuxserver.ioを信頼する必要があります。それらについて聞いたことがない。しかし、それらを見ると、彼らの全体の仕事はコンテナを作成することです。だから彼らはおそらくそれが本当に得意だ。そして、このコンテナはDockerHubから50万回以上ダウンロードされたと思われます。かなり安全なものに聞こえます。
だから私が得ている画像が
- linuxserver.ioによって作成され、
- 実際、500K回ダウンロードされた画像です。
さて、まず、（2）は真実ではありませんよね？それはコンテナのすべてのバージョンを数えていると思います。そのため、おそらくコンテナは何年もの間安全でしたが、誰かが深刻なセキュリティホールを備えたバージョンをリリースしただけです。そして（1）があります。それが本当の悪臭だ。 linuxserver.ioがコンテナーのソースであると見なしているコンテナーの元のソースコードが本当に完全に私が実際に使用しているコンテナ。それを知る方法はありません。そして、本当に、私はこのコンテナーについてだけでなく、それを作成するために使用されたすべてのサブコンテナーについても知っている必要があります。そのため、このコンテナを使用することはできません。
これは極端なケースですが、ネットワークセキュリティに関係するコンテナではおそらくそうではありません。私が実際にこのイメージを使用した50万人の消費者の多くは、linuxserver.ioのせいで、無謀にそうしたことを期待しています。
Dockerには完全なコンテナー来歴メカニズムが必要です。それでも、ここに集まるには大きな信頼があります。多分巨大すぎる。おそらく、セキュリティソフトウェアはコンテナー化できないだけかもしれません。
迅速な調査によってソースへの信頼を築くことができますが、より根本的な懸念は、コンテナーを実行するためにルートアクセスを使用する必要性によって示唆されるように、全体的なセキュリティプロファイルの相対的な未熟さです。
人気のあるソリューションに焦点を当てることをお勧めしますので、Docker Hubなどの制御されたGitベースのリポジトリを使用して、人気のベンダー提供の製品をプルダウンしていると考えてみましょう。 Gitメカニズムは、優れた信頼層を提供します。名前付きプロバイダーを信頼する場合、Docker製品を信頼できます。数年前にGitHubが侵害されたのを覚えているが、Gitの整合性署名メカニズムと公開制御により、ソースコードは問題なかった。一般的なベンダー製品を使用している場合、これらの機能はDocker公開ファイルも保護します。
コンテナを構築するDockerfileは、信頼できるGitリポジトリでホストされていないtarファイルなどにアクセスしてダウンロードできます。そのテキストファイルであるDockerfileを簡単にチェックするだけで、その領域に信頼を築くことができます。
全体的なセキュリティメカニズムは非常に若いので、ソース管理の問題に加えて、それらの脆弱性を考慮してください。セキュリティに関するドキュメントから：
Dockerセキュリティを確認する際に考慮すべき3つの主要な領域があります。
- カーネルの本質的なセキュリティと、名前空間とcgroupのサポート
- dockerデーモン自体の攻撃面
- デフォルトで、またはユーザーがカスタマイズした場合の、コンテナー構成プロファイルの抜け穴
- カーネルの「強化」セキュリティ機能とそれらがコンテナとどのように相互作用するか
セキュリティに関するトップページに3つの主要な領域があり、4つがリストされているという事実は、その領域で状況が流動的であることを示すもう1つの指標だと思います。これは素晴らしいソリューションのようですが、近い将来、ユーザーが提供する境界とポリシーによるインテリジェントな強化が必要になる場合があります。
私の経験では、特にDockerを使用することで、オープンソースコミュニティにあるものの大部分（Github上のものなど）が故意に悪意のないものであると信頼できます。 Dockerfileを読み取って、公式リポジトリからコードが取り込まれていることを確認できます（ランダムな人のフォークを使用するのではなく）。奇妙なところからコードを取得している場合は、もちろん、その特定のフォークの公式リポジトリと何が違うのかをいつでも確認できます。これは、意図的に悪意のない悪意のあるソフトウェアに遭遇する場所です。それはただのがらくたコードまたは恐ろしい設定または同等物です。私がDockerを使用した経験では、非公式のフォークを使用するコードは、フォークが探している特定の機能を提供しない限り、避けてください。公式リポジトリはフォークよりも頻繁に更新され、ほぼどこにでもあります。また、Dockerは「信頼されたビルド」と呼ばれるものを使用するので、缶に入っていると言っているものを手に入れることができます。最後に、Docker自体にも脆弱性があります。何かがおかしいと思われたときに直感を覚えるのに適切な考え方があるようです。
簡単に言うと、一般的には、Dockerリソースが公式ビルドをFROMプルし、公式リポジトリから、ソフトウェアを使用できるのと同じくらい安全です。 Docker自体にもいくつかの脆弱性がありますが、インフラストラクチャへのパッチ適用に精通している限り、問題はありません。
外部から環境に持ち込みたいものを信頼しないというデフォルトのスタンスを想定します。
それが本当に使用したいものである場合は、それを隔離し、分析し、害を及ぼさないことを確認することにより、リスクをできるだけ最小限に抑えます。
必要な機能を実行できるように、環境へのアクセスをできるだけ少なくします。
確認してください。それを更新し、更新が新しいリスクを導入しないことを確認してください。