コンテナの分離：コンテナはセキュリティの境界線になるのか #aqua #コンテナ #セキュリティ #docker #k8s
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2021年7月15日に公開された「 Container Isolation: Is a Container a Security Boundary? 」の日本語翻訳です。
コンテナの分離：コンテナはセキュリティの境界線になるのか
Docker の初期の頃から、コンテナセキュリティにおける基本的な疑問の1つは「コンテナがセキュリティの境界を構成しているのか」です。このブログではコンテナの分離レベルに関する、セキュリティの境界の主な問題について説明します。
セキュリティの境界の定義
まず、「セキュリティの境界」を定義する必要があります。マイクロソフトが脆弱性に注目する基準を記した「Security Servicing Criteria」によると、「セキュリティの境界は、信頼度の異なるセキュリティドメインのコードとデータを論理的に分離するものです」「例えば、カーネルスペースとユーザスペースの分離は、古典的でわかりやすいセキュリティ境界です」と述べています。また、CISSP 認定教材に、「セキュリティの境界とは、異なるセキュリティ要件やニーズを持つ2つの領域、サブネット、または環境の間の交点です」「セキュリティ境界は、LAN とインターネットの間など、セキュリティの高いエリアとセキュリティの低いエリアの間に存在します」と述べています。
重要なことは、第三者のコントロールに任せきりの基準では、セキュリティの境界を定義するための基準として使用できないということです。代わりに、CISSP の資料では、「セキュリティの境界を特定したら、その境界を越えた情報の流れを制御するためのメカニズムを導入する必要があります」と述べています。
主なクラウドプロバイダーの評価
2大クラウドプロバイダーである Google と IBM/Red Hat が、「コンテナはセキュリティ上の境界ではない」という見解を示しているように見えます。ここでは、プロセスに基づいて分離される Linux コンテナについて明確に言及しています。Google はブログで、「コンテナは強力なセキュリティ境界ではありません」「ホスト上の共有リソースへのアクセスにいくつかの制限を与えますが、悪意のある攻撃者がこれらの制限を回避することを必ずしも防ぐことはできません」とあるように、(Linux や Windows の名前を出さずに)コンテナはセキュリティ境界ではないと述べています。
Red Hat の Dan Walsh 氏は以前から、「Container do not contain.」という言葉を大切にしてきました。つまりは、「Docker と Linux カーネルがマルウェアから守ってくれると思い込むのはやめなさい」という意味を示しています。
独立したプラクティショナーやコンテナ技術の専門家による評価
プラクティショナーや他の独立したコンテナ技術の専門家が、コンテナのプロパティを使って、コンテナ環境での分離レベルを詳しく説明しています。彼らはコンテナのデフォルトのレイヤーを使ってコンテナの分離を強制する方法を強調し、間違いの結果について警告します。専門家は、このようなことを適切に行うために必要なレイヤーとコントロールの複雑さを示しています。
例えば、Netflix はプラクティショナーの視点から、コンテナのネイティブな機能であるユーザネームスペースをセキュリティ境界の追加要素として採用することで、コンテナに意図しない特権を与える CVE の影響を受けずに済んだと絶賛しています。しかし、Netflix の方法は、「リスクがあることは認識しつつ、私たちはセキュリティの境界の一部としてコンテナを活用することにしました」とリスクを認めた上で説明しています。
また、初期のコンテナセキュリティのパイオニアの一人である Jessie Frazelle 氏は、コンテナセキュリティのデフォルトとコンテナサンドボックス技術の違いによる強みをアピールしています。
悪魔は細部に宿る
コンテナに備わっている基本的なセキュリティの特性、その意図、そしてどのようにしてそれらを回避できるかを簡単に分析することで、この問題に光を当てることができます。
セキュリティレイヤーの整合性
Frazelle 氏は、Docker では、コンテナの分離自体にデフォルトで安全な枠組みを作成することに尽力しました。そして、それらをすべてオーケストレーターに持ち込もうとしました。コンテナのランタイムには、seccomp、AppArmor、カーネルネームスペース、cgroups、capabilities、非特権の Linux ユーザによって定義されたセキュリティレイヤーがあります。すべてのレイヤーが完全に重なることはありませんが、いくつかのレイヤーは重なります、と述べています。
コンテナランタイムのセキュリティレイヤーがうまく重ならず、コンテナの分離を回避する簡単な方法を生み出している例として、seccomp フィルタがあります。デフォルトの Docker セキュリティモデルの一部には、Linux カーネルへのシステムコールを停止する seccomp フィルタがあります。しかし、Kubernetes を使用する場合、このフィルターはデフォルトで無効になっているため、Mark Manning の keyctl-unmask のような特定の攻撃が可能になります。
コンテナのさまざまなセキュリティレイヤー間の重なり合う部分にギャップがあることは、それだけでコンテナがセキュリティの境界を構成していないと結論づけるのに十分です。
視認性の向上
標準的な Linux コンテナのさらなる課題は、コンテナを作成・管理するために使用されるプログラムが多数存在することです。例えば、コンテナの起動には runc、管理には containerd を使用し、さらに Docker などのツールで開発者向けの機能を追加できます。
特に、Docker のようなコンテナツールは、コンテナの実行を自動化し、複雑さを軽減することを目的としているため、多くのユーザはすべてのプログラムを完全には認識していないことがあります。例えば、containerd は Docker によって実行時に自動的にインストールされるます。そのため、ユーザは信頼されていないコンテナイメージを実行した場合に、ユーザの認証情報が漏れる可能性のある、ContainerDrip 脆弱性の関連性を認識していないことがあります。
Frazelle 氏は、真に安全であるためには、複数のセキュリティレイヤーが必要です。仮に1つの層に脆弱性があったとしても、攻撃者は分離メカニズムをバイパスするために、別の層にも脆弱性が存在している必要があります、と述べています。これは素晴らしいアドバイスですが、あらゆる種類のセキュリティ境界を実施するためには、まずすべての層を意識することが必要です。そして、多くのコンテナツールは、この認識と可視性を提供することを意図して作られたものではありません。同時に多くのプラクティショナーは、この可視性を得ることの重要性を理解するのに十分な知識を持っていません。
そのため、より重要なポイントは、「もし、私たちのチームがコンテナをセキュリティの境界として考えているとしたら、どのような影響があるのか」ということです。
セキュリティレイヤーは動的である
異なるプログラムの脆弱性により、セキュリティレイヤーが重なる部分と重ならない部分が変わってしまうことがあります。例えば、Docker(および CRI-O のような他のランタイム)で使用されている runc プロジェクトの最近の脆弱性により、攻撃者を含めた誰でも Pod を作成してクラスターノード上への特権アクセスを得ることができます。ユーザは、自分が runc を使用していることに気づいていないことがありますし、たとえ気づいていたとしても、このような特殊な方法で特権アクセスを得ることができることに気づいていないことがあります。
まとめ
コンテナがセキュリティの境界線であると信じているチームは、ネイティブコントロールを使って最大限のセキュリティとコンテナの分離を実現しようという気になるでしょうか。いくつかの簡単な例を見てみると、コンテナを真のセキュリティ境界として設定することの複雑さは、些細なことではありません。コンテナの構成要素や、セキュリティレイヤーがどのように重なるのか、あるいは重ならないのかについて、非常に多くの専門知識を必要とすることがわかります。そして結局、セキュリティレイヤーは完全には重なり合わず、コンテナが何らかの形でセキュリティ境界を形成しているという真の議論は排除されてしまいます。
このような課題を解決し、より厳格な境界を提供するために、さまざまなコンテナ分離技術が構築されています。これらの技術の詳細については、後日投稿予定です。
