KubeCon NA 2018のコンテナランタイムの話題ひととおり振り返ってみよう[KubeCon+CloudNativeCon NA 2018参加レポート]
こんにちは、NTTの徳永です。今年度（H30年度）に入社し、新人としてコンテナ仮想化技術、特にコンテナランタイムの勉強に取り組んでいます。
2018年12月10日から13日にかけて、世界で最大級のコンテナ技術カンファレンスであるKubeCon+CloudNativeCon NA 2018（以下、KubeCon）がシアトルで開催されました。私も参加し、コンテナランタイム領域を中心に情報を収集してきましたので、本稿でご紹介します。より詳しい内容をDocker Meetup Tokyo #27でも発表しますので、そちらの方にもぜひご参加ください。
はじめに
“The year of choice in container runtimes.”
DockerのJustin Cormack氏はセッション「How to Choose a Kubernetes Runtime」でコンテナランタイム領域における2018年をこのように表現しました。本稿で主に扱うコンテナランタイムとはKubernetes®のコンポーネントのひとつで、ノード上でkubeletから命令を受け、アプリケーションの実行単位であるPodやコンテナを作成したり、それらを直接操作する役割を持ちます。今年はセキュリティ指向のさまざまなコンテナランタイムが登場し、群雄割拠の様相を呈しています。私の前回の記事で詳しく述べましたが、それらコンテナランタイムには以下のようなものが含まれます。
gVisor（runsc）
Googleによるコンテナランタイムです。コンテナからのシステムコールをユーザ空間に再実装したシステムコールハンドラで処理することで、ホストOSへのシステムコール発行を制限します。
Nabla Containers（runnc）
IBM®によるコンテナランタイムです。unikernelとしてコンパイルしたアプリケーションをユーザ空間で実行することで、ホストOSへのシステムコール発行を制限します。
Kata Containers（kata-runtime）
OpenStack® Foundationによるコンテナランタイムです。軽量なVMをPodとして扱い、その中でコンテナを実行することでコンテナとホストOS間の隔離を強めます。
Firecracker™
AWSが11月に発表したコンテナランタイムです。Firecrackerそれ自体はコンテナランタイムの標準仕様 OCI™ Runtime Specificationを満たしませんが、現在Kata Containersや containerd®とのインテグレーションが進められており、Kubernetesで利用可能になりつつあります。
今回のKubeConでは、コンテナランタイムレイヤのセキュリティやランタイムの比較を取り上げるセッションが多く開かれ、さらにコンテナランタイムのコミュニティの議論の場としても活用されました。本稿ではKubeConにおけるそれらコンテナランタイムの話題をひととおり振り返ります。
コンテナ実行環境のセキュリティの話題
Kubernetes環境におけるセキュリティ脅威の種類
GoogleのMaya Kaczorowski氏、Brandon Baker氏のセッション「This Year, It’s About Security」（資料はこちら）によると、Kubernetes環境に対するセキュリティ脅威は以下の2つに分類できるようです。
・コンテナ外からの脅威 : DDoSやcryptominingなど
・コンテナ内からの脅威 : コンテナ内部から共有リソースへの（不正な）アクセスやコンテナ環境からの脱出など
セッションでは、今年発生したコンテナ外からの攻撃の例がいくつか紹介されました。コンテナ内からの攻撃はまだ現実には起こっていないようですが、来年以降発生する恐れはあり、Googleでもこれを深刻にとらえていると述べていました。特に同一ノード上に信頼度の違う複数のワークロードが存在する場合、コンテナ内からの脅威に備える必要があるようです。
いくつかのセッションで言及されていたように、コンテナがホストOSに攻撃を行った場合、影響はそのホストOSを共有する他のコンテナにまで波及する可能性があります。これを防ぐために、本稿冒頭で紹介したセキュリティ指向のコンテナランタイムは、Linuxカーネルのセキュリティ機能に加えてVMやユーザ空間カーネルなどの隔離レイヤを追加することで、コンテナとホストOSの隔離を強めようとしています。
コンテナランタイムで最小化できるセキュリティ脅威
それらコンテナランタイムが具体的にどのようなセキュリティ脅威を最小化するかについては、Aqua SecurityのAriel Shuper氏のセッション「Getting Your Hands “Dirty” in Container Sandbox」で述べられました。このセッションによれば、コンテナのセキュリティを包括的に保つには以下の3つの方針を考える必要があります。
・Attack’s sufaceの最小化 : 脆弱性そのものを無くす。
・Attack’s potentialの最小化 : 権限を下げることで攻撃者が環境内でできることを制限する。
・Attack’s raduisの最小化 : 攻撃の影響範囲を限定する。
この中でコンテナランタイムで担保できるのは3つめの「Attack’s raduisの最小化」であるとのことです。他のセキュリティ脅威を最小化するためには、既存のベストプラクティスしつつ、コンテナランタイムに本稿冒頭で紹介したようなセキュアなものを用いることが必要になります。
さらにこのセッションでは様々なコンテナランタイムの概要紹介や、それらのセキュリティ面と運用面での比較も行われ、それぞれにトレードオフがあることが示されました。現状では、複数のコンテナランタイムをひとつの環境下でワークロードに合わせて共存させるのが良いようです。
コンテナランタイムレイヤの具体的な脆弱性の例
コンテナランタイムレイヤで見つかった脆弱性にはCVE-2017–1002101があります。この脆弱性はKubernetes上でコンテナからストレージを扱う機構であるVolumeに対し、パスを指し示すための設定項目であるsubPathを不正に設定することでコンテナ内からホストの任意のファイルを操作できてしまうというものです。
GoogleのMichelle Au氏、Red HatのJan Šafránek氏のセッション「How Symlinks Pwned Kubernetes (And How We Fixed It)」（資料はこちら）はその脆弱性の詳細を扱ったものでした。このセッションではCVE-2017–1002101が発見されてからの、Kubernetesのセキュリティチームによるパッチ実装、公開までの一連の対応が詳しく語られました。
ホストとコンテナ間でのファイルを共有におけるリスクの高さやセキュリティ担保の難しさを実感できる、興味深いセッションでした。セッションの最後には、Volumeのセキュリティを担保するためのベストプラクティスとして、コンテナをroot権限で実行しないことや、Podの挙動をセキュアなものに制限するPodSecurityPolicyを使用することが推奨されました。
コンテナの隔離を強める新たな低レイヤ要素技術
また、コンテナランタイムレイヤだけでなく、Linuxカーネルやハードウェアレイヤでも、コンテナの隔離を強める技術の開発が進められています。GoogleのTim Allclair氏、Adin Scannell氏によるセッション「Recent Advancements in Container Isolation」（資料はこちら）では、それらがストーリー形式で紹介されました。セッションでは、Linuxカーネルで初めてコンテナという概念を扱うcontainer IDや、時間情報を隔離する新たなnamespaceであるTime namespace、また、よりハードウェアに近いレイヤの脆弱性への対策機能が紹介されました。
コンテナランタイムの紹介と使い分けの話題
このようなセキュリティ的背景をふまえ、コンテナに強い隔離を施すコンテナランタイムの紹介が、上述したセッションを含め多くのセッションで行われました。また、それらコンテナランタイムをKubernetes上でPod単位で使い分ける機能であるRuntimeClassも紹介されました。
コンテナランタイムの包括的な紹介セッション
本稿冒頭でも紹介した、DockerのJustin Cormack氏によるセッション「How to Choose a Kubernetes Runtime」（資料はこちら）では、Kata Containers、gVisor、Nabla Containers、Firecrackerの概要が紹介されました。Kata ContainersのエミュレーションオーバヘッドやgVisorの互換性の問題、Nabla Containersのイメージ作成の難しさ等については、このセッションを含めいくつかのセッションで言及されていました。このセッションに特徴的だったこととして、発表者はnested virtualizationはセキュリティの境界になりえないと考えており、Kata ContainersやgVisor（KVMモード）をnested virtualization下で実行しないことを推奨していました。最後には、コンテナランタイムの代替に加えて、コンテナの権限を降格させて実行することの重要性も述べられました。
特定のコンテナランタイムの深堀りセッション
特定のコンテナランタイムに注目し、深掘りやそれらの比較をするセッションもありました。
containerdのセッション
containerdメンテナらによる「Intro: containerd」および「Deep Dive: containerd」は、containerdについて深掘りするセッションでした。どちらのセッションでも、containerdの特徴である拡張性に注目し、APIベースのプラガブルなアーキテクチャの概要や、それによって結ばれるさまざまなコンポーネントをデモを交えて紹介していました。なおFirecrackerも、containerdの拡張性を活用し、いくつかのコンポーネントを独自実装することでcontainerdとのインテグレーションに取り組んでいます。
CRI-Oとpodmanのセッション
Red HatのDaniel Walsh氏らによる「Security Considerations for Container Runtime」は 、Kubernetes Node SIGのコンテナランタイムCRI-Oと、CRI-O由来のPod操作ツールであるpodmanを熱く推すセッションでした。まずセッション冒頭で全員起立し「I promise to say containers rather than Docker containers」と復唱させられ、Docker以外にもコンテナランタイムの選択肢があることが強調されました。その後CRI-Oとpodmanの概要がデモを交じえて紹介されました。また、RuntimeClassを用いてruncとKata ContainersをCRI-Oから使い分けるデモも行われました。CRI-Oとpodmanどちらにも共通して、セキュアな機能を持ち、かつDockerよりも軽量であるという点が強調されていました。
Kata ContainersとgVisorのセッション
hyper.shのXu Wang氏のセッション「Kata and gVisor: A Quantitative Comparison」（資料はこちら）では、Kata ContainersとgVisorの概要とその比較結果が発表されました。このセッションに特徴的だったのは、セッションタイトルにもあるように各コンテナランタイムのパフォーマンスを様々な角度から定量的に比較したという点です。パフォーマンス測定の結果、gVisorの方がmemory footprintやコンテナの起動時間については良い結果になった一方、Kata Containersの方がネットワーキング性能が良い、などのトレードオフが定量的に明らかになりました。
発表でも紹介されていましたが、最近のKata Containersは、起動済みVMを再利用するtemplate機能によるVM起動時間の改善や、ストレージドライバのパススルー機能を用いたI/O性能の改善など、最適化に積極的に取り組んでいるようです。また、ハイパバイザについてもqemuよりも軽量なnemuやFirecrackerがサポートされるようになっており、いくつかのセッションでqemuの脆弱性の多さが指摘されていることからも、今後はこれらが主流になると考えられます。
発表の最後には、gVisorのようにユーザ空間でカーネルを実行するアプローチをとる新たなコンテナランタイムであるlinuxdプロジェクトも紹介されました。
Kata ContainersとNabla Containersのセッション
Branch MetricsのRicardo Aravena氏、IBMのJames Bottomley氏によるセッション「Container Security and Multi-Tenancy Tales from Kata and Nabla」（資料はこちら）では、Kata ContainersとNabla Conainersの比較が行われました。このセッションで行われた興味深い比較のひとつに、セキュリティ面の定量的な比較がありました。
Nabla ContainersプロジェクトではセキュリティリスクをHorizontal Attack Profile（HAP）と呼ばれる方式で定量化し、それをもとにコンテナの隔離の強さの比較を試みています。HAPは実行されるカーネルコード量とバグ密度の積で求まります。ただし現状のHAPの計算方法では各システムコールごとのコードの信頼性の違いが考慮されておらず、それについては今後改善すると述べていました。セッションではDocker、gVisor、Kata Containers、Nabla ContainersについてHAPの比較が行われ、その結果Nabla Containersは実行するシステムコール数が最も少なく、HAPが最も良いという結果が示されました。
その他のコンテナランタイム関連の話題
コンテナランタイムの歴史と標準化
セキュリティ以外に、コンテナランタイム領域で取り上げられた話題には「標準化」がありました。The Linux Foundation/CNCFのChris Aniszczyk氏らによるセッション「How Standards, Specifications and Runtimes Make for Better Containers」では、コンテナ技術の歴史とその標準化団体であるOCIの概要やミッション、ロードマップなどについて述べられました。今後は「Keep things stable」の方針のもとDistribution Specificationプロジェクトや分散アプリケーションの新しいパッケージ仕様であるCNABへ取り組んでいくとのことです。
コンテナランタイムコミュニティのミーティング
KubeConはセッションのみならず、コンテナランタイムコミュニティの議論の場としてもおおいに活用されました。KubeConの場外でKata ContainersとFirecrackerのインテグレーションや、containerdとFirecrackerのインテグレーションに関わるミーティングがそれぞれのメンテナによって開かれました。
私はcontainerdとFirecrackerのミーティングに特別に参加させていただきました。ミーティングでは、はじめにFirecrackerメンテナより、containerdインテグレーションのPoC実装のデモを見せていただきました。現状のFirecrackerはcontainerdとのインテグレーションのために以下のコンポーネントを独自実装しcontainerdに組み込んでいます。
runtime（shim）
低レイヤランタイムを直接操作するコンポーネントです。Firecrackerによる実装ではmicroVM内で実行されるruncを操作します。
snapshotter
コンテナのファイルシステムやそのレイヤ管理を担うコンポーネントです。FirecrackerはコンテナイメージをブロックデバイスとしてmicroVMに見せます。
デモの後は、Firecrackerで現在開発に取り組んでいるdevicemapperベースの新しいsnappshotterや、コンテナのブートタイム、ホストとコンテナ間のファイル共有（bind mount）などについて議論が行われました。
まとめ
今年はコンテナランタイム領域の標準がほぼ固まり、その標準に沿ってセキュリティ指向のさまざまなコンテナランタイムが開発されました。KubernetesでもRuntimeClassが導入されたことで、今はそれらの比較や使い分けに注目が集まってきています。しかしいくつかのセッションで述べられたように、コンテナの隔離により防げるセキュリティ脅威は部分的であり、既存のベストプラクティスと並行した対策をしなければなりません。コンテナランタイムレイヤは今も盛んに議論が行われており、Firecrackerやlinuxdのように新しいものも登場しています。2019年も引き続き動向を追っていく必要がありそうです。
おわりに
私たちNTTは、オープンソースコミュニティで共に活動する仲間を募集しています。ぜひ弊社 ソフトウェアイノベーションセンタ紹介ページ及び、採用情報ページをご覧ください。
