[修士論文発表] Tiaccoon: コンテナネットワークにおいて複数トランスポート方式で統一的なアクセス制御

Transcript

1. Tiaccoon: Unified Access Control with Multiple Transports in Container Networks Tiaccoon: コンテナネットワークにおいて 複数トランスポート⽅式で統⼀的なアクセス制御 2024年2⽉5⽇ 修⼠論⽂発表会 岡部研究室 尾上寛弥 1
2. 背景︓コンテナネットワーク 2 コンテナ ( Dockerなど) 軽量なOSレベル仮想化技術 コンテナオーケストレーションツール ( Kubernetesなど) コンテナネットワークを⽤いて複数ホスト上の⼤量コンテナを管理
3. 背景︓アクセス制御 コンテナネットワークにおいて 管理者の指定したポリシーでのアクセス制御が必要 TCP/IPのパケット処理(カプセル化・NAPTなど)を⽤いた コンテナオーバーレイネットワークで実現 3 A B DB A A X Y Y X
4. 背景︓様々なトランスポート⽅式 UNIXドメインソケット 同じホスト上のコンテナ間のみで使⽤可能 スループット⼤ レイテンシ⼩ 4
5. 背景︓様々なトランスポート⽅式 RDMA(Remote Direct Memory Access) 専⽤のハードウェアを持つホスト間のコンテナ通信を⾼速化 5 スループット⼤ レイテンシ⼩ CPU時間⼩ コネクション 確⽴時間⼤
6. 課題 コンテナネットワークのアクセス制御を保ちながら ホストの特性に合わせたトランスポート⽅式の使い分けが困難 6 コン テナ コン テナ 10.0.0.1 10.0.0.2 拒否 /var/a.sock /var/b.sock 拒否 アクセス制御ポリシーの記述・適⽤が トランスポート⽅式に依存 アプリがトランスポート⽅式を選択 するために実装が環境に依存
7. 提案︓Tiaccoon 7 ソケットAPIの処理を置換し 特定のトランスポート⽅式に依存しない アクセス制御・コンテナ通信を実現 Tiaccoon Controller Tiaccoon Server Client Tiaccoond Tiaccoon 1. API UNIX /var/b-web.sock 2. 3. 4. bind (:80) connect (10.10.0.1:80) 10.10.0.1:80 UNIX /var/b-web.sock 10.10.0.1:80 TCP/IP 172.16.0.1:3001 10.10.0.1:80 RDMA 192.168.0.1:701 policy: - type: ALLOW client: labels: - app: client-b - role: web server: labels: - app: server-a - role: web 10.10.0.2 app:client-b role:web 10.10.0.1 app:server-a role:web
8. 貢献 • スループット・レイテンシ・CPU時間の悪化なしに ソケットAPIを⽤いる複数トランスポート⽅式で 統⼀的なアクセス制御を可能にした • 複数のコンテナネットワーク⾼速化⼿法を 柔軟に選択することでコンテナネットワーク のパフォーマンスを向上させた 8
9. 関連研究 AF_GRAFT[Nakamura 2018],AppSwitch[Subhraveti 2017],Flower,NetKernel[Niu 2022],IETF TAPS 複数トランスポート⽅式の利⽤を提案しているが、柔軟なトランスポート⽅式の選択や アクセス制御・UNIXドメインソケットやRDMAの考慮がない Acila[Ohnishi 2022] ラベルベースのポリシーをIdentifier単位のエントリに変換してアクセス制御 AF_GRAFT[Nakamura 2018], Slim[Zhuo 2019], O2H[Choochotkaew 2022], ShuntFlow[Liu 2023], ONCache[Lin 2023], bypass4netns[Matsumoto 2024] コネクション単位アクセス制御の後にTCP/IPネットワークスタックをバイパスして⾼速化 FreeFlow[Kim 2019], SocksDirect[Li 2019], MasQ[He 2020], TSoR[Sun 2023] RDMAのためのコンテナ仮想ネットワーク・アクセス制御を提案 9
10. 提案︓Tiaccoon 10 ソケットAPIの処理を置換し 特定のトランスポート⽅式に依存しない アクセス制御・コンテナ通信を実現 Tiaccoon Controller Tiaccoon Server Client Tiaccoond Tiaccoon 1. API UNIX /var/b-web.sock 2. 3. 4. bind (:80) connect (10.10.0.1:80) 10.10.0.1:80 UNIX /var/b-web.sock 10.10.0.1:80 TCP/IP 172.16.0.1:3001 10.10.0.1:80 RDMA 192.168.0.1:701 policy: - type: ALLOW client: labels: - app: client-b - role: web server: labels: - app: server-a - role: web 10.10.0.2 app:client-b role:web 10.10.0.1 app:server-a role:web
11. 提案︓Tiaccoon ソケットAPIをフックしてアクセス制御・トランスポート⽅式選択・ソケット作成 IPアドレス・ポート番号をTCP/IPのアドレスではなく識別⼦として利⽤ コンテナ(の集合)に仮想IPアドレス、アプリケーションに仮想ポート番号 コンテナのラベルで記述された通信先サーバー・アクセス制御ポリシーをエントリに変換し適⽤ 11 Tiaccoon Controller Tiaccoon Server Client Tiaccoond Tiaccoon 1. API UNIX /var/b-web.sock 2. 3. 4. bind (:80) connect (10.10.0.1:80) 10.10.0.1:80 UNIX /var/b-web.sock 10.10.0.1:80 TCP/IP 172.16.0.1:3001 10.10.0.1:80 RDMA 192.168.0.1:701 policy: - type: ALLOW client: labels: - app: client-b - role: web server: labels: - app: server-a - role: web 10.10.0.2 app:client-b role:web 10.10.0.1 app:server-a role:web
12. 提案︓サーバー側のソケットAPI 12 Tiaccoon 1. API TCP/IP Client Server 3. 2. Tiaccoon 4. RDMA (rsocket) UNIX 1. API 3. listen 2. 4. close (FD) accept (FD) listen (FD) bind (FD,IP,Port) bind Server Tiaccoon &bind listen listen&accept (accept ) accept ( ) send, recv close close accept FD
13. 提案︓クライアント側のソケットAPI 13 1. API TCP Client Serv 3. 2. Tiaccoon 4. connect Client Tiaccoon connect (FD,IP,Port) send, recv close close (FD) close &connect
14. 提案︓トランスポート⽅式の選択 サーバーコンテナを 指定するラベル条件と アプリが公開する仮想ポート番号を 管理者がサーバーポリシーとして登録 利⽤可能なトランスポート⽅式の サーバーホストアドレスを決定し サーバーエントリとして登録 Tiaccoonはサーバーエントリの選択 によりトランスポート⽅式を選択 14 Tiaccoond Tiaccoon policies: - labels: - app: server-b - role: web port: 80 IP 10.10.0.1 ( ) 80 IPv4 172.16.0.1:3001 10.10.0.1 ( ) 80 UNIX (HostX) /var/b-web.sock 10.20.0.2 ( ) 80 IPv4 172.16.0.1:3001 10.20.0.2 ( ) 80 RDMA (RoCEv2) 192.168.0.1:701 10.20.0.2 ( ) 80 UNIX (HostX) /var/b-web.sock Tiaccoon Controller IP
15. 提案︓アクセス制御 ラベルベースの アクセス制御ポリシー を仮想アドレスベースの アクセス制御エントリ に変換して適⽤ Tiaccoonはクライアントと サーバーの仮想アドレスから エントリを⾒つけて適⽤ 15 NIC Tiaccoon Controller or 10.0.0.1 ) 10.10.0.1 ( ) DENY 10.0.0.1 ( ) 10.10.0.2 ( ) ALLOW 10.0.0.1 ( ) 10.0.0.2 ( ) DENY 10.0.0.1 ( ) 10.0.0.3 ( ) DENY 10.0.0.1 ( ) 10.0.0.4 ( ) ALLOW policy: - type: DENY priority: 10 client: labels: - app: client-b - role: web server: labels: role: web - type: ALLOW priority: 100 client: labels: - app: client-b - role: web server: labels: - app: server-a role: web Tiaccoon Tiaccoond
16. 実装︓ソケットAPIフック seccomp_unotifyを利⽤してアクセス制御・トランスポート⽅式選択 TCP/UNIXではSECCOMP_IOCTL_NOTIF_ADDFDでソケット置換 16 Sock FD seccomp unotify Kernel Userland Tiaccoon ) ( ) FD Return Return SECCOMP_IOCTL_NOTIF_ADDFD
17. 実装︓RDMA アクセス制御&トランスポート⽅式選択をseccomp_unotifyで ソケット作成をLD_PRELOADでロードしたrsocket for Tiaccoonで コンテナにSR-IOVのVirtual Function(VF)を割り当て 17 seccomp unotify Kernel Userland Tiaccoon RDMA socket (SR-IOV) Return rsocket for Tiaccoon Sock FD ( ) RDMA
18. 評価 スループット・レイテンシ・CPU時間 1送信あたりのデータサイズ・ソケットバッファサイズを変えながら Netperfを使⽤して10秒間の平均を計測 コネクション確⽴&Close時間 connect, closeシステムコールが完了する時間を10000回計測 16コアCPUを持つ物理マシン2台を RDMA(RoCEv2)対応の100Gbps Ethernet NICで直結 18
19. 評価︓TCP/IPコンテナオーバーレイネットワーク vs. Tiaccoon 19 TCP/IP, UNIX, RDMA全てでスループット・レイテンシ・CPU時間向上
20. 評価︓ホストネットワーク vs. Tiaccoon 20 TCP/IP, UNIX, RDMA全てでスループット・レイテンシ・CPU時間が同等
21. 評価︓コネクション確⽴&Close時間 21 TCP/IP, RDMA, UNIX全てで悪化
22. 議論︓通信性能 トランスポート⽅式の選択 条件を満たした環境下で⾼速なトランスポート⽅式を利⽤する ことでTCP/IPよりもスループット・レイテンシ・CPU時間向上 コンテナのTCP/IPネットワークスタックのバイパス ソケット置換によりスループット・レイテンシ・CPU時間向上 コネクション確⽴ システムコールフック・トランスポート⽅式選択・アクセス制御・ ソケット置換による追加の処理によりコネクション確⽴時間の悪化 22
23. 議論︓コンテナネットワークの要件 Isolation 同じホスト上の他コンテナと 競合せずに通信できる Portability ホストに依存しない仮想アドレス を⽤いて他コンテナと通信できる Controllability 管理者のみがネットワークポリシー (アクセス制御・レートリミット・QoS) を適⽤できる →Tiaccoonは要件を満たす 23 Tiaccoon 172.16.0.15:3001 /var/app-a.sock 172.16.0.16:4002 /var/app-a.sock Tiaccoon Tiaccoon Tiaccoon 10.0.0.1 10.0.0.2 Tiaccoon Controller
24. まとめ・今後の課題 特定のトランスポート⽅式に依存しないアクセス制御・コンテナ通信を実現 ソケットAPIの処理置換によりラベルベースのアクセス制御・トランスポート⽅式選択 コネクション型プロトコルにおいてコンテナオーバーレイネットワークの代替が可能 コンテナオーバーレイネットワークより⾼性能&ホストネットワークと同等の スループット・レイテンシ・CPU時間 コネクション確⽴時間の悪化 今後の課題 コネクションレスプロトコルへの対応・ソケットAPIに限らない完全なアクセス制御・ 他のトランスポート⽅式への適⽤・細粒度のトランスポート⽅式選択 →より広い状況でより⾼性能なコンテナ間通信を実現できる可能性 24