異種OS機能連携によるセキュアコンテナ実現に向けたFreeBSD上でのCNI準拠コンテナネットワーキングの実現/IOT64

IOT64

Transcript

1. 異種OS機能連携によるセキュアコンテナ実現に向けた FreeBSD上でのCNI準拠コンテナネットワーキングの実現 2024/3/12 IOT研究発表会 坂口 颯麻　（公立はこだて未来大学） 鈴木 進太郎（公立はこだて未来大学） 中田 裕貴　（さくらインターネット株式会社） 松原 克弥　（公立はこだて未来大学）
2. 2 背景：コンテナ型仮想化 コンテナ型仮想化はクラウドコンピューティング基盤上で広く活用される コンテナ：OSカーネルが提供するリソース分離・制御機能を用いて 実現されるアプリケーション実行環境 ハードウェア ホスト OS コンテナ ランタイム コンテナ アプリ ケーション コンテナ アプリ ケーション 構築・実行 • コンテナランタイムからの構築・実行 • ホストOSカーネル共有による 軽量かつ高速な起動
3. 3 背景：コンテナ型仮想化の課題 • OSカーネルの共有を悪用した、 コンテナへの攻撃 • 頻繁なコンテナ間通信を悪用した、 コンテナネットワークに対する攻撃 ホストOSカーネルの脆 弱性を悪用した 攻撃が可能 中間者攻撃 による通信 本来の通信 悪意のあるコンテナによる通 信に対する攻撃が可能
4. 4 先行研究: 異種OS機能連携によるセキュアコンテナ 中田らの研究 [1] 目的: コンテナの軽量さを最大限維持しつつ、OSカーネル共有に起因する 　　 脆弱性を悪用した攻撃を回避できるセキュアコンテナの実現 [1] Nakata, Y., Suzuki, S. and Matsubara, K.: Reducing Attack Surface with Container Transplantation for Lightweight Sandboxing, Proceedings of the 14th ACM SIGOPS Asia-Pacific Workshop on Systems. pp. 58-64 (2023). 手法: • 異種OSとしてFreeBSDを採用 • jailと、Linuxエミュレータによる Linuxコンテナ互換実行 jail: コンテナ相当の機能を持つ FreeBSDの仮想化技術 • Linuxコンテナ互換に対する FreeBSD固有のセキュリティ機構の適用 課題: コンテナネットワーキング関しては未検討
5. 5 コンテナ型仮想化におけるネットワークの重要性 クラウドコンピューティング基盤で用いるマイクロサービスアーキテクチャと呼ばれる設計手法では、コンテナ 型仮想化を活用する コンテナ型仮想化における ネットワークの重要性は高くなっている マイクロサービス アーキテクチャ コンテナ コンテナ コンテナ コンテナ コンテナ マイクロサービスの コンテナによって 多数の通信が発生 する
6. 6 目的: 異種OS機能連携によるセキュアコンテナ実現に向けて 本研究では、 異種OS機能連携によるセキュアコンテナ実現のためのネットワーキング機構の実現を目指す 異種OS機能連携によるセキュアコンテナをクラウドコンピューティング基盤へ導入することを想定 コンテナネットワーキングに関して Linuxと同等な機能が必要 となる
7. 7 実現すべきネットワーキングの要件 要件2. Linuxのコンテナ間通信と同等の機能によるネットワーク構築 • Linuxコンテナネットワーキングの標準規格に準拠することで 同等の操作で同等のネットワーク構築が可能 • 攻撃回避の要である異種 OS上で動作していることの 隠蔽を行う 要件1. 細粒度なコンテナ間ネットワーク分離 • 使用用途に合わせたネットワークリソースの分離が可能 • Linuxのネットワーク分離機構と同等の機能
8. 8 要件1: 細粒度なコンテナ間ネットワーク分離の Linuxにおける実現 Network Namespace • ネットワークに関するシステムリソースの分離を行う機能 細粒度な分離のパターン New Share Inherit コンテナ作成時に 新しい分離 を追加 既存のNetwork Namespaceに コンテナが参加 コンテナ間で隔離を行わず、 ホストのネットワークを共有
9. 要件1: 細粒度なコンテナ間ネットワーク分離の Linuxにおける指定 New Share Inherit “linux”: { “namespace”: [ { “type”: “network” } ] } “linux”: { “namespace”: [ { “type”: “network”, “path”: “/var/run/netns/…” } ] } “linux”: { “namespace”: [ (設定なし ) ] } 9 • ネットワーク隔離は低レベルコンテナランタイム が行う - 低レベルコンテナランタイム：コンテナの構築・削除や、ネットワーク隔離を行う • config.jsonという設定ファイルを用いる
10. 10 要件1: ネットワーク隔離機構の FreeBSDでの現状 vnet • Network Namespace相当のネットワーク隔離機能を提供 • vnetは、jailごとにネットワーク隔離をする • jailとvnetは1-1対応のため、Shareのネットワーク分離が不可能 New Share Inherit FreeBSD環境で利用可能な Shareの実現が必要
11. 11 要件1: ネットワーク隔離指定手法の FreeBSDでの現状 • vnetは、低レベルコンテナランタイムが利用する • 一部設定を書き換えたconfig.jsonを利用できる • Shareのネットワーク分離を指定する方法がない New Share Inherit ”freebsd”: { “vnet”: { “mode”: “new” } } ”freebsd”: { “vnet”: { “mode”: “inherit” } } conifg.jsonによるShareの指定手法の確立 が必要
12. Network Namespace 12 要件2: Linuxコンテナネットワーキングの標準規格 Contaier Network Interface（CNI） • コンテナのネットワーク接続・削除に関する定義 • ADDやDELなど定義を満たした実行可能ファイルであるCNIプラグインの提供 ◦ calico ◦ flannel • 高レベルコンテナランタイムが ネットワーク構築を行う - 高レベルコンテナランタイム： 低レベルランタイムへの命令や、 CNIプラグインによるネットワーク設定 コンテナ ネットワーク 設定 コンテナランタイム 実行 CNI プラグイン Network Namespaceの パスを指定
13. 13 要件2: ネットワーク構築機構の FreeBSDでの現状 • 基本的なネットワーク設定を行うCNIコアプラグインが実装されている ◦ bridge plugin ◦ filewall plugin ◦ host-local plugin ◦ loopback plugin • 高レベルコンテナランタイムから 利用する • 分離されたネットワーク空間を 指定する方法に差異 • jailを指定するファイルパスは存在しない Linuxと同等の操作を行うために 違いを吸収する必要がある vnet jail ネットワーク 設定 コンテナランタイム 実行 CNI プラグイン Jail IDを指定
14. 14 FreeBSDにおける現状の課題まとめ containerd nerdctl runj CNI コンテナの設定 コンテナの構 築命令 ネットワークの構 築命令 Shareのような コンテナ間通信を行う際は Newと仮想ブリッジを用いる vnetはファイルパスがない ため、Shareの指定でもCNIでの指 定でもLinuxと異なる • コンテナランタイム制御ツールとして nerdctl、高レベルコンテナランタイムとして containerd、 低レベルコンテナランタイム runjが利用可能 ファイルパスではなく、 jail IDを指定する Shareを指定する方法がない
15. 15 本研究のアプローチ 既存のjailとvnetを利用した Network Namespace互換の実現 CNIプラグインの差異の吸収 Network Namespace互換 containerd nerdctl runj CNI コンテナの設定 コンテナの構 築命令 ネットワークの構 築命令 CNIプラグインの指定方法の 違いを吸収する 機構の実装 jailとvnetを利用した Shareの実現機能 の実装 Share指定のための設定 を追加 Shareのためのファイルパス 作成機構の実装 Linuxと同等の指定方法である ファイルパス により、 ネットワーク構築が可能に コンテナ間で同一の ネットワークリソースを 利用可能に ＝ Shareの実現
16. 16 Shareの実現 vnetによりネットワーク隔離を施した jail内に複数の jailを入れ子構築 • vnetでは実現不可能だった 複数jail間での ネットワーク空間共有 を可能に • vnet jail上に複数のjailを入れ子で 構築する機構を低レベルコンテナラ ンタイムrunjに実装
17. 17 Shareのための指定手法 “freebsd”:{ “network”:{ “vnet”:{ “mode”:”share”, “path”:”/var/lib/runj/jails/c1/netns” } } } FreeBSDのネットワーク隔離設定 既存jail内に入れ子構築するための ”mode”: “share”の追加 vnet jail指定のための ”path”の追加 “linux”:{ “namespaces”:[ { “type”:”network”, “path”:”/proc/***/ns/net” } ] } Linuxのネットワーク隔離設定 指定するNetwork Namespace用ファイルを jailごとに作成する機構を runjに実装 C1 C2
18. 18 CNIプラグインの差異の吸収 nerdctlにNetwork Namespace互換をパスで指定する 機構の追加 受け取ったパスを Network Namespace 互換jailのjail IDに変換 Network Namespace互換jailに ネットワーク設定を行う
19. 19 実際の動作のデモ : Share netns1 my_container
20. 20 実際の動作のデモ : Share
21. 21 実際の動作のデモ : Share netns1 my_container 0e348a…
22. 22 実際の動作のデモ : Share
23. 23 実際の動作のデモ : Share netns1 my_container 0e348a… epair0a 同一のネットワークインタフェースが確認可能 ・名称 ・MACアドレス ・IPアドレス
24. 24 実際の動作のデモ : FreeBSDの隠蔽 Linuxのifconfigでは eth0と表示される FreeBSDのifconfigでは epair0bと表示される
25. 25 評価1：jailの入れ子構造による通信性能確認 目的 • jailの入れ子構造が通信性能に及ぼす影響の確認 条件 • ネットワークベンチマークツール Netperf (ver. 2.7.1)を利用 • NetperfはLinuxバイナリを使用 • vnet jail - host間とNetwork Namespace互換jail内のjail -host間の スループットを20回算出し、平均による比較 実験環境 OS FreeBSD 14.0-RELEASE CPU Intel Core i5-4278U (4) @ 2.60GHz RAM 16 GB
26. 26 評価1：jailの入れ子構造による通信性能比較の結果 スループットに大きな違いがない Linux vnet jail: 63085.017 (trans/s) nested jail: 63226.806 (trans/s) jailを入れ子で構築するによって 通信性能に影響を与えることはない ことが推測できる jailの入れ子によるネットワーク リソースの共有が有用である事を 示した
27. 27 評価2：jailの入れ子構造によるオーバーヘッド確認 目的 • jailの入れ子構造が通信以外の性能に及ぼす影響の確認 条件 • ベンチマークツール UnixBench (ver. 5.1.3)を利用 • Linux jailとvnet jail内に入れ子で構築された Linux jail内でそれぞれ 10回ずつ値を算出し、その平均を比較 実験環境 OS FreeBSD 14.0-RELEASE CPU Intel Core i5-4278U (4) @ 2.60GHz RAM 16 GB
28. 28 評価2：jailの入れ子構造によるオーバーヘッド評価の結果 各項目で同等のパフォーマンスが 見られた jailを入れ子で構築する事による コンテナ内アプリケーション性能 への影響は小さい といえる
29. 29 評価3：Network Namespace互換機能によるコンテナ間通信の性能評価 目的 • FreeBSDでの従来のコンテナ間通信と実装した Shareの 通信特性の調査 条件 • ネットワークベンチマークツール Netperf (ver. 2.7.1)を利用 • NetperfはLinuxバイナリを利用 • 2つのvnet jail間(bridge経由)とNetwork Namespace互換jail内の 2つのjail間のスループットを20回算出し、平均による比較 実験環境 OS FreeBSD 14.0-RELEASE CPU Intel Core i5-4278U (4) @ 2.60GHz RAM 16 GB
30. 30 評価3：Network Namespace互換機能によるコンテナ間通信の性能評価の結果 New×2 bridge: 63113.5845 (trans/s) Share: 72260.6775 (trans/s) 本研究の提案手法によって、 FreeBSD環境でのコンテナ間通信を Linuxと同等の機能としたことが、 性能面でも通信特性が変わったこと から確認できる
31. 31 今後の課題 • 構築するネットワークのセキュリティに関する調査と制御 ◦ 現状ではネットワークのセキュリティを考慮していない →FreeBSD固有のセキュリティ機構を用いた、 　細粒度なネットワークアクセス制御やリソース制御機構の実装を検討
32. 32 まとめ 背景: 異種OS機能連携によるセキュアコンテナ実現のための課題 コンテナネットワーキングの重要性 目的: 異種OS機能連携によるセキュアコンテナ実現のための FreeBSD環境におけるCNI準拠ネットワーキング機構の実現 提案: Linux Network Namespace互換機能の実現 CNIプラグインの差異の吸収 実装: runjを用いたshareの実現と指定手法の確立 　　 nerdctlを用いたCNIプラグインのファイルパスによる指定の確立 評価: jailの入れ子構造による通信性能とオーバヘッドの確認 　　 Shareによるコンテナ間通信の性能評価
33. 33 - 付録 -
34. 34 実際の動作のデモ : New
35. 35 Kubernetesのネットワーク定義 [2] Cloud Native Computing Foundation: Services, Load Balancing, and Networking, https://kubernetes.io/docs/concepts/services-networking. ((Accessedon 2024/1/25)) 1. 各Podはそれぞれ一意なIPアドレスを持ち、Pod内のコンテナはIPを共有していて、localhost 経由で相互に通信することが可能である。 2. ノード上のすべてのPodは、Pod間通信が可能である。 3. すべてのPodはクラスタ内のすべての PodとNATなしで通信することが可能である。
36. 36 ネットワーク隔離機構 動的なリソース制限が可能な、 FreeBSD固有のセキュリティ機構 CapsicumとCasperの Linuxコンテナネットワーキング互換機構への適用を実現する • Capsicum/Casperを拡張し、ネットワーク互換機構に適用することで、 最粒度なネットワーク隔離機構を実装 コンテナ内 アプリケーション Capsicum サンドボックス グローバルなリソース Casper プロセス リソースに対する アクセスを制限する Capsicumサンドボックス内から発行 された関数に対して 検査・代理実行を行う Casper関数 を発行 プロセスに対して、 グローバルなリソースへのアク セスを制限する