コンテナが侵害された場合、それはホストも侵害されたことを意味しますか？
最近、コンテナーと呼ばれる新しい仮想化技術について聞いたことがあります。コンテナーが侵害されたとしたら、これはホストも侵害されていることを意味しますか（コンテナーはホスト上のプロセスであるため）？セキュリティの観点から、VM（仮想マシン））はコンテナより安全ですか？
コンテナでカーネルが危険にさらされている場合、ホストが危険にさらされています。
表面上、侵害されたコンテナがホストに害を及ぼすことはできません。ただし、コンテナのセキュリティは優れていないため、通常、特権のあるコンテナユーザーがホストを危険にさらす脆弱性が数多くあります。このように、コンテナは多くの場合、完全な仮想マシンよりも安全性が低くなります。これは、仮想マシンが ハッキングされる できないことを意味するものではありません。それらは単にかなり悪いわけではありません。
カーネルが仮想マシンで悪用される場合でも、攻撃者はハイパーバイザーのバグを見つける必要があります。カーネルがコンテナで悪用されると、ホストを含むシステム全体が危険にさらされます。これは、コンテナーを使用する場合、カーネルのセキュリティバグは、クラスとしてははるかに深刻であることを意味します。
多くの場合、コンテナは namespaces を使用して実装されます。
名前空間は、グローバルシステムリソースを抽象化してラップし、グローバルリソースの独自の独立したインスタンスを持っているという名前空間内のプロセスから見えるようにします。グローバルリソースへの変更は、名前空間のメンバーである他のプロセスからは見えますが、他のプロセスからは見えません。
残念ながら、Linuxの名前空間は通常、カーネルからはるかに大きな攻撃対象領域を公開しています。 多数カーネル脆弱性ある悪用可能 名前空間内。すべてのコンテナソリューションがLinux名前空間を使用するわけではありませんが、それらはすべて同じ種類のテクノロジを使用し、 同じセキュリティの問題 を使用します。 Dockerなどの一部のコンテナーは、seccompと呼ばれるsyscallフィルタリングフレームワークを利用して、カーネルの攻撃対象領域を減らすことができます。これは改善ですが、必ずしも十分ではありません。
から Daniel Shapira ：
[...]カーネルエクスプロイトは、コンテナ化された環境に壊滅的な影響を与える可能性があります。これは、コンテナがホストと同じカーネルを共有しているため、組み込みの保護メカニズムを信頼するだけでは十分ではないためです。
コンテナーはVMほど分離されていないため、はい、ある意味ではコンテナーの安全性は低くなります。森の答えを見てください。
そうは言っても、コンテナーはアプリケーションのセキュリティの観点からいくつかの利点を提供することにも注目する価値があると思います。通常、これらは単一のプロセスを実行して攻撃対象を制限するため、コンテナ内で実行されているcronモニターやsshデーモンはありません。コンテナイメージは不変です。再起動すると、元のバイナリから読み込まれます。アプリケーションを上書きすることはできません。ほとんどのコンテナテクノロジーでは、どのポートが誰に対して開かれているかを正確に制御することもできます。他のコンテナー以外からはアクセスできないDBのコンテナーを作成できます。
これはすべて、これらの機能が宣伝どおりに機能し、もちろん欠陥がないことを前提としています。そして、攻撃者がなんとかコンテナから脱出できた場合、上記のいずれも当てはまりません。それは少しオーバーヘッドを追加しますが、ベルトとサスペンダーのアプローチが可能です：VMの上のコンテナー。