Kata Containersの創設者が安全なコンテナ技術を紹介します

1. 由来：安全容器の命名

Phil Karlton は、「コンピューター サイエンスにおいて本当に難しい問題は、キャッシュの無効化と命名という 2 つだけです」と有名な​​言葉を残しています。

コンテナ コミュニティに属する私たちにとって、「命名」はまさにこの文に値するものだと私は信じています。これは間違いなく、古い開発者を沈黙させ、新しい開発者を泣かせるものである。システム ソフトウェアに関して言えば、現在一般的に言及されている概念は「 Linux コンテナー テクノロジー」です。これは、Jail、Zone、Virtual Server、Sandbox などとも呼ばれています。同様に、初期の仮想化テクノロジ スタックでは、仮想マシンの一種はコンテナとも呼ばれていました。結局のところ、この単語自体は、包含、カプセル化、分離するために使用されるオブジェクトを指します。これは非常に一般的なため、厳密さで知られる Wikipedia のエントリでは「OS レベルの仮想化」と呼ばれており、「コンテナーとは何か」という質問を避けています。

2013年にDockerが発表されて以来、コンテナの概念は、不変インフラストラクチャやクラウドネイティブなどの一連の概念とともに、その後の数年間で圧倒的な力で「ソフトウェアパッケージ+構成」のきめ細かい組み合わせに基づくアプリケーション展開を覆し、シンプルな宣言型ポリシーと不変コンテナでソフトウェアスタックが明確に定義されました。アプリケーションのデプロイ方法は、ここでは少し話題から外れているようです。ここで強調したいのは次の点です。

「クラウド ネイティブのコンテキストにおけるコンテナーは、本質的には「アプリケーション コンテナー」、つまり標準形式でカプセル化され、標準のオペレーティング システム環境 (通常は Linux ABI) 上で実行されるアプリケーション パッケージ、またはこのアプリケーション パッケージを実行するプログラム/テクノロジーです。」

この定義は私自身のものですが、私の個人的な意志ではありません。これは、OCI 仕様のコンセンサスに基づいて記述されています。この仕様では、コンテナのルート ファイル システム上のどの実行ファイルが実行されるか、どのユーザーがそれを実行するか、どのような CPU が必要か、どのようなメモリ リソースと外部ストレージが利用可能か、どのような共有要件があるかなど、コンテナ内のアプリケーションが配置される環境と実行方法を指定します。

したがって、アプリケーションを中心に、標準フォーマットと標準オペレーティング システム環境をパッケージ化したものこそが、アプリケーション コンテナのパッケージ化となります。

このコンセンサスに基づいて、安全なコンテナについて話し合うことができます。当時、共同創業者の Zhao Peng と私は、私たちの技術を「仮想化コンテナ」と名付けましたが、注目を集めるために、「VM のように安全、コンテナのように高速」というスローガンを使用しました。その結果、コンテナのセキュリティ問題に悩む人たちは、すぐにこれを「セキュアコンテナ」または「セキュアコンテナ」と呼ぶようになり、止められなくなりました。私たちにとって、このテクノロジーは分離の追加レイヤーであり、セキュリティの一部にすぎませんが、ユーザーは依然としてこれをセキュア コンテナーと呼ぶことを好みます。安全なコンテナの定義は次のとおりです。

セキュア コンテナーは、コンテナー アプリケーションに完全なオペレーティング システム実行環境 (通常は Linux ABI) を提供するランタイム テクノロジですが、アプリケーションの実行をホスト オペレーティング システムから分離して、アプリケーションがホスト リソースに直接アクセスするのを防ぎ、コンテナー ホスト間またはコンテナー間で追加の保護を提供します。

これは私たちの安全なコンテナです。

2. 間接層: セキュアコンテナの本質

安全なコンテナについて話すとき、「間接層」という用語に言及する必要があります。これは LinuxCon 2015 での Linus Torvalds 氏の発言です。

「セキュリティ問題に対する唯一の正しい答えは、バグの発生を許容しつつ、追加の分離レイヤーでそれらをブロックすることです。」

安全のために分離レイヤーを導入する必要があるのはなぜですか?実際、Linux 自体の規模は非常に大きく、プログラムにバグがないことを理論的に検証することは不可能です。したがって、適切なバグが悪用されると、セキュリティ リスクがセキュリティの問題になります。セキュリティ フレームワークとパッチだけではセキュリティは保証されないため、脆弱性と、それらの脆弱性による完全な侵害のリスクを軽減するために、追加の分離が必要です。

ここで、安全なコンテナが役立ちます。

3. Kata Containers: クラウドネイティブ仮想化

2017 年 12 月、KubeCon で Kata Containers セキュア コンテナー プロジェクトをリリースしました。このプロジェクトには、私たちが以前に開始した runV と、Intel の Clear Container プロジェクトという 2 つの前身があります。どちらのプロジェクトも 2015 年 5 月に開始されており、これは実際には Linus 氏が KubeCon 2015 で発言する前のことです。

彼らのアイデアは非常にシンプルです。

• オペレーティング システムのコンテナー メカニズム自体ではセキュリティの問題を解決できないため、分離レイヤーが必要になります。
• 仮想マシン (VM) 自体は、既成の分離レイヤーです。たとえば、Alibaba Cloud と AWS はどちらも仮想化技術を使用しています。したがって、ユーザーが「VM のセキュリティ」を実現できる限り、セキュリティはパブリック クラウドのニーズを満たすことができると広く信じられています。
• 仮想マシンにカーネルがあれば、先ほど説明した OCI 定義をサポートでき、つまり Linux ABI オペレーティング環境が提供されます。このオペレーティング環境で Linux アプリケーションを実行することは難しくありません。

現在の問題は、仮想マシンの速度が十分でないため、コンテナ環境での適用が妨げられていることです。 「コンテナのスピード」を実現できれば、分離のために仮想マシンを使用する安全なコンテナ技術を実現できる可能性があります。これは、仮想マシンをKubernetesのPodSandboxとして利用するという、Kata Containers自体のアイデアです。 Kata で使用される VM には、qemu、firecracker、ACRN、cloud-hypervisor などがあります。

次の図は、Kata Containers が Kubernetes と統合される様子を示しています。ここでの例では containerd を使用していますが、もちろん CRI-O も同様です。

現在、Kubernetes では Kata コンテナが一般的に使用されています。まず、Kubelet は CRI インターフェースを通じて containerd または CRI-O を見つけます。このとき、ミラーリングなどの操作は、containerd または CRI-O によって実行されるのが一般的です。リクエストに基づいて、ランタイム要件を OCI 仕様に変換し、実行のために OCI ランタイムに渡します。たとえば、上の図の上部にある kata-runtime、または下部にある合理化された containerd-shim-kata-v2 などです。具体的なプロセスは以下のとおりです。

• containerd はリクエストを受け取ると、まず shim-v2 を作成します。この shim-v2 は PodSandbox の代表であり、VMM の代表でもあります。
• 各 Pod には、containerd/CRI-O のさまざまな操作を実行する shim-v2 があります。 shim-v2 はこのポッドの仮想マシンを起動し、その中で Linux カーネルを実行します。これは図のゲスト カーネルです。これに qemu が使用される場合、いくつかの構成とパッチによってサイズが小さくなります。同時に、このシステムには追加のゲスト オペレーティング システムはなく、CentOS や Ubuntu のような完全なオペレーティング システムは実行されません。
• 最後に、コンテナ仕様と、rootfs やファイルシステムを含むコンテナ自体によってパッケージ化されたストレージを PodSandbox に引き渡します。この PodSandbox は、kata-agent を介して仮想マシン内のコンテナを起動します。
• CRI セマンティクスと OCI 仕様によれば、複数の関連コンテナを Pod 内で起動できます。これらは同じ仮想マシンに配置され、必要に応じて特定の名前空間を共有できます。
• これらに加えて、ホットスワップモードを介して他の外部ストレージやボリュームもこの PodSandbox に接続できます。
• ネットワークの場合、現在 tcfilter を使用してほぼすべての Kubernetes CNI プラグインにシームレスにアクセスできます。また、コンテナのネットワーク機能を向上させる特別な CNI プラグインが含まれるエンライトモードも提供しています。

ご覧のとおり、PodSandbox には、実際にはいくつかのコンテナ パッケージングとコンテナ アプリケーションを実行するゲスト カーネルのみがあり、完全なオペレーティング システムは含まれていません。つまり、このプロセスは従来の仮想マシンのようには使用されません。コンテナに関してはコンテナエンジンのみを搭載し、不要なメモリの使用を抑え、共有できるメモリを共有することでメモリのオーバーヘッドをさらに削減します。

従来の仮想マシンと比較すると、オーバーヘッドが少なく、起動が高速です。ほとんどのシナリオでは、「VM と同じくらい安全」かつ「コンテナと同じくらい高速」になります。同時に、セキュリティ技術に加えて、動的なリソースのプラグとプラグの取り外しや、virtio-fs などの技術の使用など、従来の仮想マシンと比較して柔軟性が高く、マシンの物理的な操作が少なくなっています。これは、ホストの基本ファイル システム (コンテナーの rootfs など) の内容を仮想マシンと共有するために、Kata などのシナリオ向けに特別に設計されたテクノロジです。

以前に不揮発性ストレージと不揮発性メモリ用に開発された DAX テクノロジーの一部により、異なる PodSandbox 間、つまり異なる Pod と異なるコンテナ間で、共有可能な読み取り専用メモリ部分を共有することが可能になりました。これにより、異なる PodSandbox 間で大量のメモリを節約できます。同時に、すべての Pod 管理は外部からの Kubernetes コンテナ管理を通じて行われ、メトリックやデバッグ情報は仮想マシンにログインしているという感覚なく、外部から取得されます。つまり、非常にコンテナ化された操作のように見えます。最下層では依然として仮想マシンですが、実際にはクラウドネイティブの仮想化です。

4. gVisor: プロセスレベルの仮想化

プロセスレベルの仮想化とも呼ばれる gVisor は、kata とは異なる方法です。

2018 年 5 月、コペンハーゲンで開催された KubeCon で、Google は kata コンテナへの対応として 5 年間社内で開発してきた gVisor セキュア コンテナをオープンソース化し、異なるセキュア コンテナ ソリューションがあることを示しました。

Kata Containers が既存の分離テクノロジを組み合わせて変更することでコンテナ間の分離レイヤーを構築するのであれば、gVisor の設計は明らかにより簡潔になります。

上図の右側に示すように、Go 言語で書き直され、ユーザー モードで実行されるオペレーティング システム カーネルです。このカーネルの名前は Sentry です。仮想化や仮想マシン技術に依存しません。それどころか、内部的にはプラットフォームと呼ばれる機能を使用して、ホスト オペレーティング システムが操作を実行し、オペレーティング システム上のアプリケーションの予想されるすべての操作を Sentry に転送して実行できるようにします。処理後、Sentry は処理の一部をオペレーティング システムに渡して完了を支援し、大部分は自動的に完了します。

• gVisor の開発者は、まず攻撃対象領域を減らす必要があります。ホスト オペレーティング システムは、サンドボックス内のアプリケーションへのシステム コールの約 20% のみを提供します。

Linux には 300 を超える Syscall があります。実際、Sentry が最終的にオペレーティング システムに対して開始する呼び出しは、60 を超える Syscall にのみ集中します。これは、gVisor の開発者がオペレーティング システムのセキュリティについて調査した結果、オペレーティング システムに対する攻撃のほとんどが、あまり使用されないシステム コールから発生することが判明したためです。

これは理解しやすいことです。あまり使用されないシステム コールの実装パスは一般に古いパスであるため、これらの部分の開発は一般にあまり活発ではなく、少数の開発者だけがメンテナンスしていることになります。人気のあるパス上のコードは、何度もレビューされるため、より安全です。したがって、gVisor の設計では、アプリケーションがオペレーティング システム レベルであまり使用されない Syscall にアクセスするのを防ぎ、それらを Sentry でのみ処理します。

Sentry からホストにアクセスする場合、検証済み、成熟済み、人気のあるパス上のシステム コールのみが使用されます。こうすることで、セキュリティは当初の印象よりもはるかに向上します。システムコール率は元の 1/5 になりましたが、攻撃を受ける可能性は 1/5 未満です。

• 次に、ファイルを開く操作である open() など、頻繁に攻撃されるシステム コールの一部を分離する必要があることがわかりました。

Unix システムでは、ほとんどのものがファイルであるため、open ではさまざまなことが行われ、ほとんどの攻撃は open を通じて実行されます。 gVisor の開発者は、Gofer と呼ばれる独立したプロセスでオープンを実装しました。分離されたプロセスは、実際には、seccomp、いくつかのシステム制限、およびいくつかの「機能ドロップ」によって保護されたコンテナーです。 Gofer は作業量が少なく、非ルートでも実行できるため、システム全体のセキュリティがさらに向上します。

• 最後に、Sentry と Gofer はどちらも、従来の C 言語ではなく Go 言語で実装されています。

Go 言語自体はよりメモリセーフな実装であるため、gVisor 全体が攻撃に対して脆弱でなくなり、メモリの問題が発生する可能性も低くなります。もちろん、Go 言語はいくつかの領域ではまだシステムレベルとしては十分ではありません。 gVisor の開発者は、これを実現するために Go ランタイムに多くの調整を加え、それを Go 言語コミュニティにフィードバックしたことも認めています。

gVisor のアーキテクチャは非常に美しいと言えます。多くの開発者が、gVisor のアーキテクチャが非常に気に入っており、よりシンプルで、より純粋で、よりクリーンだと考えていると私に話してくれました。もちろん、そのアーキテクチャは美しいものの、カーネルを再実装できるのは Google のような大企業だけです。 Microsoft の WSL 1 も同様かもしれません。このデザインは非常に先進的ですが、実際にはいくつか問題があります。

• まず、Sentry は Linux ではないため、Kata などのソリューションと比較すると互換性にはまだ一定のギャップがあります。これを回避する方法はありませんが、特定のアプリケーションでは問題にならない可能性があります。
• 次に、システム コールと CPU 命令システムの現在の実装では、アプリケーションから Syscall をインターセプトし、Syscall を Sentry に送信して実行します。このプロセス自体にはかなりのオーバーヘッドがあります。特定のシナリオでは、gVisor はより優れたパフォーマンスを実現できます。ただし、ほとんどのシナリオでは、gVisor のパフォーマンスは Kata などのソリューションに比べて劣ります。

したがって、短期的には、gVisor のようなソリューションは究極のソリューションにはなりませんが、特定のシナリオに適応し、インスピレーションをもたらすこともできます。この発見は将来のオペレーティング システムや CPU 命令セットの開発に何らかの影響を与える可能性があると思います。そして、将来的には Kata と gVisor の両方が進化し、アプリケーション実行の問題を統一的に解決する公開ソリューションが登場することを期待しています。

5. 安全なコンテナ: セキュリティだけではない

セキュア コンテナーの名前はセキュリティですが、提供されるのは分離のみです。その役割は安全性だけではありません。

セキュア コンテナーは分離レイヤーを使用して、外部の悪意のある攻撃や偶発的なエラーに起因するアプリケーションの問題がホストに影響を与えたり、異なる Pod 間で相互に影響を与えたりすることを防ぎます。したがって、実際には、この追加の分離レイヤーはセキュリティだけでなく、他の側面にも影響を及ぼします。システムのスケジュール、サービス品質、アプリケーション情報の保護に役立ちます。

従来のオペレーティング システム コンテナ テクノロジは、カーネル プロセス管理の拡張であると言えます。コンテナ プロセス自体は、関連するプロセスのグループです。ホストのスケジュールシステムから完全に表示されます。 Pod 内のすべてのコンテナまたはプロセスもホストによってスケジュールおよび管理されます。つまり、コンテナの数が多い環境の場合、ホストカーネル自体にかかる負担が非常に大きくなるということです。この負担によって生じるオーバーヘッドは、多くの実際の環境で観察できます。

特に、コンピュータ技術の継続的な発展により、オペレーティング システムには大量のメモリ、多数の CPU が搭載されるようになり、数百 GB のメモリも珍しくありません。この場合、割り当てられたコンテナの数が多いと、スケジューリング システムに非常に大きなオーバーヘッドが発生します。セキュア コンテナーを採用すると、ホスト マシン上で完全な情報を表示できなくなります。分離レイヤーは、分離レイヤー上のアプリケーションのスケジュールも担当します。したがって、ホスト マシン上でスケジュールする必要があるのはサンドボックス自体のみであり、ホスト マシンのスケジュール オーバーヘッドが削減されます。これにより、スケジュールの効率が向上します。

スケジューリング効率を向上させると同時に、すべてのアプリケーションを相互に分離することで、コンテナ間およびコンテナとホスト間の干渉を回避し、サービス品質を向上させます。別の観点から見ると、安全なコンテナを作成する本来の目的は、コンテナ内の悪意のあるアプリケーションや問題のあるアプリケーションによるホストへの影響を防ぐことです。逆に言えば、クラウドとしては悪意のある攻撃に直面する可能性もあるので、自分自身を守るためでもあります。

同時に、ユーザーは私たちが自分たちのリソースに過度にアクセスすることを望んでいません。ユーザーはリソースを使用する必要がありますが、データを私たちが確認する必要はありません。セキュア コンテナは、ユーザーがコンテナ内で実行する内容を完全にカプセル化できるため、ホストの運用および保守管理操作ではアプリケーション データにアクセスできず、ユーザー データに触れることなくサンドボックス内のアプリケーション データを保護できます。クラウドとしてユーザーデータにアクセスする場合、ユーザーに承認を求める必要があります。この時点では、ユーザーには悪意のある操作があるかどうかはわかりません。サンドボックスが適切にカプセル化されていれば、追加のユーザー認証要件は必要なくなり、ユーザーのプライバシー保護に役立ちます。

将来を見据えると、安全なコンテナはセキュリティの分離だけではないことがわかります。セキュア コンテナ分離層のカーネルは、ホスト マシンのカーネルから独立しており、アプリケーション サービス専用です。この観点から見ると、実際にはホストとアプリケーションの間で機能の合理的な割り当てと最適化が行われています。大きな可能性を秘めています。将来のセキュア コンテナーは、分離パフォーマンスのオーバーヘッドを削減するだけでなく、アプリケーションのパフォーマンスも向上させる可能性があります。分離テクノロジーにより、クラウドネイティブ インフラストラクチャがより完璧になります。

VI.結論

この記事の主な内容はここで終わります。以下に、皆様に簡単に要約します。

• 現在、いわゆる「セキュア コンテナ」とは、コンテナ アプリケーションに完全なオペレーティング システム実行環境 (通常は Linux ABI) を提供するコンテナ ランタイム テクノロジを指しますが、アプリケーションの実行をホスト オペレーティング システムから分離して、アプリケーションがホスト リソースに直接アクセスするのを防ぎ、コンテナ ホスト間またはコンテナ間で追加の保護を提供します。
• Kata Containers は、仮想化を使用して分離レイヤーを提供するオープンソースの安全なコンテナー プロジェクトです。 Kubernetes などのクラウド ネイティブ エコシステムと完全に互換性があります。このプロジェクトは OpenStack Foundation によってホストされ、Ant Financial と Intel が共同で主導しています。
• gVisor は、プロセスレベルの仮想化テクノロジーを使用する安全なコンテナ テクノロジーです。これは Google によって開発され、オープンソース化されており、Go 言語でユーザー モード互換のカーネルを実装しています。
• 最後に、セキュア コンテナーによって提供される分離は、セキュリティの一部であるだけでなく、パフォーマンス、スケジュール、管理の観点からも分離を提供できます。