2021.08.17

コンテナの分離：コンテナはどのようにして実現しているか #aqua #コンテナ #セキュリティ #docker #k8s

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本ブログは「Aqua Security」社の技術ブログで2021年7月21日に公開された「 How Do Containers Contain? Container Isolation Techniques 」の日本語翻訳です。

コンテナの分離：コンテナはどのようにして実現しているか

コンテナを長く扱っている方は、コンテナがセキュリティの境界として考えるべきではないことを、既にご存知でしょう。このブログでは、さまざまなコンテナ分離技術がどのようにしてこの問題に対する解決策を提供しようとしているのか、そしてそのメリットとデメリットから、何が実用的な選択となるのかを探っていきます。

コンテナ分離技術

大まかに言って、Linuxコンテナでは、含まれるアプリケーションを基礎となるホストや環境で実行されている他のアプリケーションから分離するために、3つのアプローチがあります。

Linuxコンテナ- containerd や Docker、CRI-O などのコンテナランタイムは、Linux のネームスペースを使用してコンテナを分離します。そして、cgroups、seccompフィルタ、ケイパビリティなどの他の OS の機能を使用して、含まれるプロセスができることを制限します。1つの VM 上で動作するすべてのコンテナは、単一の OS カーネルを共有しています。これが最も一般的なユースケースです。
サンドボックスベースのコンテナ- Google gVisor のようなサンドボックスでは、含まれるプロセスは実質的にカーネルを共有しています。しかし分離のために Linux の機能を使用するのではなく、専用のセキュリティサンドボックスを使用して、ネットワークなどのリソースを提供したり、カーネルリソースを必要とするアプリケーションのシステムコールを仲介したりします。
VM ベースのコンテナ- AWS Firecracker のようなソフトウェアでは、ハイパーバイザーを使用して分離します。パフォーマンスへの影響を最小限に抑えるため、一般的に軽量な VM が使用されます。この分離は、ハイパーバイザーのセットアップと実質的には同じです。仮想ハードウェアの完全なサポートなど、標準的なハイパーバイザーの機能の多くが必要ないため、これらの機能を無効にできるという利点があります。

分離の範囲

さて、分離のための 3つのアプローチを説明したところで、セキュリティの境界の問題に戻りましょう。重要なのは、どのアプローチも完璧な分離を提供するものではないということです。なぜならば、どのアプローチにも脆弱性があるからです。しかし、私たちが注目できるのは、それぞれのアプローチの相対的な攻撃対象領域の大きさです。攻撃対象領域が大きければ大きいほど、攻撃される可能性が高くなります。

この 3つのアプローチのうち、Linux コンテナで採用されているプロセスベースの分離は、明らかに最大の攻撃対象領域を持っています。Linux カーネルは公開されており、それは非常に複雑です。新しいコンテナを作成してその分離を管理するプロセスには、このタスクを念頭に置いて設計されていないさまざまなメカニズムが使用されています。その結果、スタックのさまざまな層で、何度も問題が発生しています。最近公開された runc の問題 CVE-2021-30465 や containerd の abstract shimmer の問題は、いずれもその複雑さと、攻撃者がそれを悪用してコンテナの制約から逃れる方法を示す良い例です。

プロセスベースのコンテナの大きな攻撃対象領域と共有リソースは、他の分野にも現れています。DoS や、共有 VM でホストされた「ノイジーネイバー」のリスクを防ぐために、たとえば cgroups 等を使用した追加の制御が必要です。また、コンテナ間での情報漏洩の可能性に関するリスクもあります。

プロセスベースのコンテナがまったく分離されていないと言っているわけではありません。一部のユースケースでは、提供されている分離機能は完全に適切なものです。しかし、より高度なセキュリティシナリオでは、コンテナの分離を補完する追加のコントロールが必要になります。

プロセスベースの分離とサンドボックスの分離の違いは、典型的な設計上の意図の違いです。gVisor のようなソリューションは、ホスト上のプロセスのセキュリティ分離に特化して設計されているため、このユースケースに焦点を当て、コンテナと基盤となるホストの間のインタフェースを強化できます。

サンドボックス環境では、追加の制御を必要とする領域がいくつかあります。特にリソース管理の領域では、コンテナが同じホスト上に存在するため、「ノイジーネイバー」のリスクを軽減するために cgroup の設定が必要になります。

ハイパーバイザベースのコンテナ分離では、サンドボックスとは異なるアプローチで、含まれる各プロセスに完全な Linux カーネルを提供します。ハイパーバイザは一般的にセキュリティの境界を提供するように設計されており、完全な Linux カーネルよりも攻撃対象がかなり小さくなります。さらに、Firecracker のようなケースでは、ハイパーバイザーのインタフェースをさらに強化し、従来の攻撃の原因となっていた仮想ハードウェアなどの機能を排除しています。

分離によるトレードオフ

もちろん、他のテクノロジーの選択と同様に、コンテナ分離のアプローチを選択する際にはトレードオフがあります。1つ目は、パフォーマンスへの影響の可能性です。Firecracker は、VM ベースのコンテナ分離のための初期のアプローチに比べて、パフォーマンスを向上させるためにかなりの努力をしています。しかし、コンテナごとにフルの Linux カーネルを起動することは、ある程度の影響があります。また、gVisor のようなサンドボックス型のアプローチでも、パフォーマンスに影響を与える傾向があるという研究結果もあります。

分離レイヤーを追加することでコンテナの使用に影響を及ぼす可能性があるのは、コンテナが Linux コンテナ化に固有の柔軟性を利用する場合です。例えば、監視のためにホストのネットワークスタックへのアクセスを必要とするコンテナがあり、コンテナのプロセスを分析することで動作するように設計されたセキュリティソリューションは、サンドボックス化されたソリューションや VM ソリューションで動作するように適応する必要があるでしょう。

コンテナ分離方法の選択

では、これらのアプローチのうち、どの方法が皆さんのコンテナに適しているのでしょうか。一般的には、運用しているアプリケーションや環境の脅威モデルによって異なりますが、考慮すべき一般的な原則がいくつかあります。

信頼されていないユーザが起動するプロセスベースのコンテナが、基盤となるホストへ侵入できないようにすることは、異なるグループの多くのプロジェクトの協力を必要とする複雑なプロセスです。コンテナとホストの間のインタフェースは、最近いくつかの脆弱性の対象となっています(こちらの記事を参照ください)。信頼できるチームが立ち上げたアプリケーションで、主に社内向けのものであれば、攻撃のリスクは軽減され、プロセスベースの分離で適切なレベルの分離が可能になると思われます。

サンドボックスやハイパーバイザーによって、コンテナセキュリティモデルに内在する柔軟性を制限することがあるため、完全な柔軟性を維持しながらコンテナの分離を実施するための最良のソリューションの 1つは、強力なデフォルト制御機能とサードパーティのセキュリティソリューションを組み合わせることです。例えば、ワークロードの保護を強化したい場合は、AdmissionController(環境内のコンテナのセキュリティコンテキストを制限する)やランタイムセキュリティコントロール(攻撃を検知して対応する)などの分野が、これらのリスクを軽減するのに役立ちます。

コンテナを起動するユーザが完全には信頼できない環境下で分離を維持したい場合(マルチテナント型の Kubernetes クラスターなど)は、サンドボックスやハイパーバイザーを使用して分離することを検討してください。