Googleがセキュアな分離を提供する軽量コンテナランタイム・サンドボックスの"gVisor"をリリース

Googleが新たなタイプのサンドボックスであるgVisorをリリースした。完全な仮想マシン(VM)で動作する場合よりも少ないリソースで、セキュアに隔離されたコンテナ実行環境を提供する。その中心となるのが、Linuxのシステムサーフェスの大部分を実装した、オープンソースのユーザ空間カーネルである。このカーネルはGo言語で記述されており、既存のコンテナとは異なるトレードオフの下で設計されている。プロジェクトには“runsc”と呼ばれる、DockerやKubernetesと統合されたOpen Container Initiative(OCI)ランタイムも含まれる。

プロジェクトのGitHubにあるREADMEによると、gVisorのコアには、権限のない通常のプロセスとして動作し、Linuxシステムコールの大部分をサポートするカーネルがある。gVisor内で動作するアプリケーションは、VM内と同じように、ホストやその他のサンドボックスとは別の専用カーネルと仮想化デバイスを取得する。gVisorはアプリケーションのシステムコールをインターセプトして、ゲストカーネルとして振る舞うことにより、強力な分離境界を提供する。この動作は、“完全なVMよりも柔軟なリソースフットプリントと低い固定コスト”を備えた、極端な準仮想化オペレーティングシステムと考えられる。一方で、この柔軟性には、パフォーマンスと互換性のトレードオフが伴う。システムコールを多用するワークロードに対しては、十分なパフォーマンスを提供できない場合があるのだ。また、LinuxシステムAPIの大部分(現時点では200のシステムコール)は実装済みだが、サポートされていないシステムコールやパラメータ(/procおよび/sysファイルシステムの一部も含まれる)が存在するため、すべてのアプリケーションが動作するとは限らない。

gVisorを発表したGoogle Cloud Platform(GCP)ブログの記事では、コンテナはアプリケーションの開発、パッケージ、デプロイの方法に革命を起こしたが、一方でコンテナに対して公開されるシステムサーフェスは広く、セキュリティ専門家が“信頼できない、あるいは悪意のある可能性を持ったアプリケーションの実行には推奨しない”と評価するに足るものだ、と述べている。この主張を裏付けるものとして、ブログではopensource.comの記事“Are Docker containers really secure?”を引用している。ただしこの記事は2014年に公開されたものであり、コンテナのセキュリティを取り巻く状況は、特にDockerに関しては当時と大きく変わっている点に注意が必要だ。

その一方で、現在のカーネル技術には、以前にInfoQの記事“Dockerとセキュアなマイクロサービス – Aaron Grattafiori氏のDockerCon 2016での講演より”で取り上げたように、広く認識されたセキュリティ上の課題が存在することも事実である。おもな課題のひとつは、単一の共有カーネルの採用による効率性とパフォーマンスの向上が、同時に、ひとつの脆弱性によってコンテナからの脱出を可能にすることも意味している点だ。そのためGoogleは、異種性の高く信頼性の低いワークロードを実行したいという要求の増加が、サンドボックス化されたコンテナ、すなわち“ホストOSとコンテナ内で動作するアプリケーションとの間に、セキュアな分離境界を提供可能なコンテナ”に対する新たな興味を呼び起こしていると考えている。

gVisorはアプリケーションがアクセス可能なカーネルサーフェスを制限する一方で、アプリケーションが必要とするすべての機能へのアクセスを提供しようとしている。一般的なカーネルとは異なり、gVisorは物理的リソースの固定的なセットを想定ないし必要とせず、既存のホストカーネルの機能を活用して、通常のユーザ空間のプロセスとして動作する。アプリケーションの発行するすべてのシステムコールをインターセプトして、それを提供するために必要な処理を行なうのだ。他のコンテナテクノロジに比較した場合の大きな違いは、gVisorが単にアプリケーションのシステムコールをホストカーネルにリダイレクトするのではなく、カーネルのおもなプリミティブ(シグナル、ファイルシステム、ミューテックス、パイプ、メモリ管理など)を実装した上で、これらを基盤とした完全なシステムコールハンドラを備えている点だ。

多重防御(defense-in-depth)を提供してホストシステムのサーフェスを制限するため、gVisorランタイムは２つの独立したプロセスに分離されている。まず最初に、カーネルを実装したSentryが、ユーザコードの実行とシステムコールの処理を行なう。次に、サンドボックス外のシステム操作(内部処理や一時ファイル、パイプなど以外)は、Goferと呼ばれるプロキシへ、9Pコネクション経由で送信される。

Sentryは、基本的なコンテキスト切り替えとメモリマップ機能を実装したプラットフォームを必要とする。現在のgVisorは２つのプラットフォームをサポートしている。Ptraceプラットフォームでは、ホストのシステムコールを実行せずにユーザコードを実行するためにSYSMENU機能を使用する。またKVMプラットフォーム(試験実装)では、SentryがゲストOSとVMM(Virtual Machine Monitor)の両方として機能することで、２つの世界をシームレスに行き来することができる。

gVisorは、OSIランタイムAPIに準拠した“runsc”(“run Sanboxed Container”の略)を介してDockerとKubernetesと統合されている。runscランタイムは、Dockerのデフォルトコンテナランタイムであるruncと置き換えが可能だ。Kubernetesでは、リソース分離の大部分はpodレベルで行なわれているため、gVisorのサンドボックスのバウンダリとして適切である。Kubernetesコミュニティでは現在サンドボックスpod APIを策定中で、すでに試験的サポートが公開されている。runscランタイムは、cri-oまたはcri-containeredプロジェクトのいずれかを使用して、KubeletのメッセージをOCIランタイムコマンドに変換することにより、Kubernetes内のサンドボックス化されたpodを実行することができる。

関連プロジェクトのひとつであるKata Containersは、“究極的に軽量な”VMを使用して、コンテナの隔離に必要なリソースフットプリントを最小限とする、オープンソースのプロジェクトである。gVisorと同様、KataにもOCIランタイムが含まれており、DockerおよびKubernetesと互換性がある。HackerNews上では２つのテクノロジ間のトレードオフに関して、長く議論が続けられている。ユーザの“jsolson”は、“これら[2つのサンドボックス技術の]間のトレードオフは、互換性、セキュリティバウンダリの堅牢性、パフォーマンスに関するものだ中心である”と示唆している。

gVisorは、メモリ安全性および型安全性の理由からGolang(Go)で記述されている。現時点ではx86_64 Linux 3.17以降でのみビルドおよび実行が可能であること、サンドボックス内ではx86_64バイナリのみがサポートされている(32ビットバイナリは動作しない)ことに注意が必要だ。

詳細な情報はGitHubのgVisorリポジトリで公開されている。また、議論に加わりたい開発者のためのGoogleグループも用意されている。