Tiaccoon: コンテナネットワークにおいて 複数トランスポート⽅式で統⼀的なアクセス制御 2024年11⽉13⽇ 電気情報通信学会 インターネットアーキテクチャ(IA)研究会 尾上 寛弥 ⼩⾕ ⼤祐 岡部 寿男 1 Slide: https://onoe.dev/ia202411

背景︓コンテナ 2 Slide: https://onoe.dev/ia202411 コンテナ︓軽量なOSレベル仮想化技術 コンテナオーケストレータ︓複数ホスト上の複数コンテナを管理 ホスト ホスト ホスト コンテナオーケストレータ コン テナ コン テナ コン テナ コン テナ コン テナ コン テナ

背景︓コンテナネットワーク Isolation 同じホスト上の他コンテナと 競合せずに通信できる Portability ホストに依存しない仮想アドレス を⽤いて他コンテナと通信できる Controllability 管理者のみがネットワークポリシー (アクセス制御・レートリミット・QoS) を適⽤できる Slide: https://onoe.dev/ia202411 3 10.0.0.1 10.0.0.2 172.16.0.15 172.16.0.16 管理者 コンテナオーケストレータ :80 :443 :80 :443

背景︓コンテナネットワーク Isolation 同じホスト上の他コンテナと 競合せずに通信できる Portability ホストに依存しない仮想アドレス を⽤いて他コンテナと通信できる Controllability 管理者のみがネットワークポリシー (アクセス制御・レートリミット・QoS) を適⽤できる Slide: https://onoe.dev/ia202411 4 10.0.0.1 10.0.0.2 172.16.0.15 172.16.0.16 管理者 コンテナオーケストレータ :80 :443 :80 :443

背景︓コンテナネットワーク Isolation 同じホスト上の他コンテナと 競合せずに通信できる Portability ホストに依存しない仮想アドレス を⽤いて他コンテナと通信できる Controllability 管理者のみがネットワークポリシー (アクセス制御・レートリミット・QoS) を適⽤できる Slide: https://onoe.dev/ia202411 5 10.0.0.1 10.0.0.2 172.16.0.15 172.16.0.16 管理者 コンテナオーケストレータ :80 :443 :80 :443

背景︓コンテナネットワーク Isolation 同じホスト上の他コンテナと 競合せずに通信できる Portability ホストに依存しない仮想アドレス を⽤いて他コンテナと通信できる Controllability 管理者のみがネットワークポリシー (アクセス制御・レートリミット・QoS) を適⽤できる Slide: https://onoe.dev/ia202411 6 10.0.0.1 10.0.0.2 172.16.0.15 172.16.0.16 管理者 コンテナオーケストレータ :80 :443 :80 :443

背景︓アクセス制御 コンテナネットワークにおいて管理者の指定したポリシーでの アクセス制御が必要 →TCP/IPのパケット処理(カプセル化・NAPTなど)を⽤いた コンテナ仮想ネットワークで実現 Slide: https://onoe.dev/ia202411 7 サービスA サービスB DB A サービスC コンテナX テナントA コンテナP テナントB コンテナQ テナントB コンテナY テナントA

背景︓様々なトランスポート⽅式 UNIXドメインソケット 同じホスト上のコンテナ間通信を⾼速化 RDMA(Remote Direct Memory Access) 専⽤のNICを持つホスト間の コンテナ通信を⾼速化 複数トランスポート⽅式の併⽤ アプリとネットワークの分離 により複数トランスポート⽅式の 利⽤を可能に 8 Slide: https://onoe.dev/ia202411 RNIC RNIC RDMA RNIC NIC TCP/IP UNIX コン テナ コン テナ コン テナ コン テナ

課題 コンテナネットワークのアクセス制御を保ちながら ホストの特性に合わせたトランスポート⽅式の使い分けが困難 Slide: https://onoe.dev/ia202411 9 コン テナ コン テナ 10.0.0.1 10.0.0.2 拒否 /var/a.sock /var/b.sock 拒否 アプリ ？ アクセス制御 トランスポート⽅式の選択

課題︓アクセス制御 アクセス制御ポリシーの記述・適⽤が トランスポート⽅式に依存 • トランスポート⽅式ごとに 異なるポリシーを⽤意して適⽤ • コンテナが頻繁に増減・移動する環境で それぞれのポリシーを管理 • トランスポート⽅式ごとに実装が必要 • TCP/IPベースのコンテナ仮想ネットワークを併⽤ • 最初にTCP/IPのコネクションを確⽴ →他のトランスポート⽅式に置換 • TCP/IPベースのコンテナ仮想ネットワークは 性能に問題あり Slide: https://onoe.dev/ia202411 10 コン テナ コン テナ 10.0.0.1 10.0.0.2 拒否 /var/a.sock /var/b.sock 拒否

課題︓トランスポート⽅式の選択 アプリがトランスポート⽅式を選択する必要がある ⾃分と通信先の双⽅のホスト上でどれを使うのが最適か︖ をアプリは判断できない アプリへの追加の実装が必要 • トランスポート⽅式の選択 • トランスポート⽅式ごとのアドレス指定・通信 Slide: https://onoe.dev/ia202411 11 アプリ ？

関連研究︓アクセス制御 Kubernetes コンテナやコンテナの集合に対してラベルを付与 アクセス制御ポリシーをラベルやIPアドレスで指定 Flannel, Cilium, Calico コンテナネットワークの接続性・アクセス制御を提供するCNI Plugin実装 Iptables, IPVS, eBPFなどによりLB・アクセス制御を実装 Acila[Ohnishi 2022] IPv6パケット単位でラベルベースのアクセス制御を提案 →いずれもTCP/IPに限った⼿法 Slide: https://onoe.dev/ia202411 12

関連研究︓トランスポート⽅式 Slipstream[Dietz 2015], vSocket[Wang 2019] TCP/IP接続確⽴後にUNIXドメインソケットやRDMAへ置換 →TCP/IPに依存・トランスポート⽅式使い分けの考慮なし Rsocket RDMA通信のためのソケットAPI FreeFlow[Kim 2019], MasQ[He 2020] RDMAベースのコンテナ仮想ネットワーク・アクセス制御 →RDMAのみで利⽤可能 AF_GRAFT[Nakamura 2018], AppSwitch[Subhraveti 2017], CloudABI Flower 複数トランスポート⽅式の利⽤ →最適なトランスポート⽅式の選択やアクセス制御の考慮なし Slide: https://onoe.dev/ia202411 13

Tiaccoond 1. ソケットAPIを フック 4. ソケット代理作成 Tiaccoond UNIX RDMA TCP/IP 5. ソケットを コンテナへ置換 アプリ アプリ アプリ 3. トランスポート ⽅式選択 NIC RNIC RNIC 2. アクセス制御 アプリ Tiaccoond (Rsocket) 提案︓Tiaccoon ソケットAPIで通信するトランスポート⽅式について 特定のトランスポート⽅式に依存しない アクセス制御・コンテナ通信を実現 Slide: https://onoe.dev/ia202411 14

Tiaccoond 1. ソケットAPIを フック 4. ソケット代理作成 Tiaccoond UNIX RDMA TCP/IP 5. ソケットを コンテナへ置換 アプリ アプリ アプリ 3. トランスポート ⽅式選択 NIC RNIC RNIC 2. アクセス制御 アプリ Tiaccoond (Rsocket) 提案︓Tiaccoon ソケットAPIをフックし、ホスト上のデーモン(Tiaccoond)が アクセス制御・トランスポート⽅式の選択をしてから ホスト上でソケット代理作成・コンテナへの置換 Slide: https://onoe.dev/ia202411 15

Tiaccoond 1. ソケットAPIを フック 4. ソケット代理作成 Tiaccoond UNIX RDMA TCP/IP 5. ソケットを コンテナへ置換 アプリ アプリ アプリ 3. トランスポート ⽅式選択 NIC RNIC RNIC 2. アクセス制御 アプリ Tiaccoond (Rsocket) 提案︓Tiaccoon IPアドレス・ポート番号をアドレスではなく識別⼦として利⽤ コンテナ(の集合)に仮想IPアドレス、アプリに仮想ポート番号 コンテナ(の集合)に紐づくラベルをもとにしたアクセス制御 Slide: https://onoe.dev/ia202411 16

提案︓受信側の通信の流れ Slide: https://onoe.dev/ia202411 17 bind アプリ Tiaccoond bindフック (PID,FD,IP,Port) 各トランスポート⽅式で ソケット作成&bind listen 各ソケットで listen&accept listenフック (PID,FD) accept acceptフック (PID,FD) acceptされたソケットの アクセス制御 コンテナに置換 新しいFDを返す send,recvで データ通信 close closeフック (PID,FD) 各ソケットをclose アプリ 1. accept 呼び出し 2. フック 4. コンテナ に置換 3. acceptされた ソケットの アクセス制御 Tiaccoond

提案︓送信側の通信の流れ Slide: https://onoe.dev/ia202411 18 connect アプリ Tiaccoond connectフック (PID,FD,IP,Port) アクセス制御 トランスポート ⽅式選択 send,recvで データ通信 close closeフック (PID,FD) 作成した ソケットをclose ソケット作成 connect コンテナに置換 アプリ 1. connect 呼び出し 2. フック 5. コンテナ に置換 3. アクセス制御 トランスポート ⽅式選択 Tiaccoond 4. ソケット 作成 connect

提案︓トランスポート⽅式の選択 管理者はラベルで指定した受信側コンテナが 通信を受け⼊れる仮想ポート番号(サーバー) をTiaccoon Controllerに登録 Tiaccoondは利⽤可能なトランスポート⽅式 の宛先物理アドレスを決定し通信先エントリ としてTiaccoon Controllerに通知 Tiaccoondは他ホストの通信先エントリを Tiaccoon Controllerから受け取る Slide: https://onoe.dev/ia202411 19 Tiaccoond NIC Tiaccoon Controller 通信先エントリ 仮想IPアドレス 仮想 ポート番号 トランス ポート⽅式 宛先物理 アドレス 10.10.0.2(コンテナ集合) 80 IPv4 172.16.0.1:3001 10.10.0.2(コンテナ集合) 80 UNIX(HostA) /var/b-web.sock server: - labels: - app: server-b - role: web port: 80 管理者 サーバー登録 サーバー 配布 エントリ 通知 仮想IP アドレス 紐付け

提案︓トランスポート⽅式の選択 受信側 ⾃ホストの通信先エントリをもとに 複数トランスポート⽅式でソケット作成&bind Slide: https://onoe.dev/ia202411 20 アプリ Tiaccoond bind(:80) listen 172.16.0.1:3001 /var/b-web.sock 通信先エントリ 仮想 ポート番号 トランス ポート⽅式 宛先物理 アドレス 80 IPv4 172.16.0.1:3001 80 UNIX(HostA) /var/b-web.sock Tiaccoon Controller 通信先エントリ 通知

提案︓トランスポート⽅式の選択 送信側 宛先コンテナとトランスポート⽅式の選択を同時に実施 ⾼速なトランスポート⽅式を優先して通信先エントリを選択 Slide: https://onoe.dev/ia202411 21 アプリ Tiaccoond connect (10.10.0.2:80) /var/b-web.sock 通信先エントリ 仮想IPアドレス 仮想 ポート番号 トランス ポート⽅式 宛先物理 アドレス 10.10.0.2(コンテナ集合) 80 IPv4 172.16.0.1:3001 10.10.0.2(コンテナ集合) 80 IPv4 172.16.0.2:3101 10.10.0.2(コンテナ集合) 80 UNIX(HostA) /var/b-web.sock Tiaccoon Controller 通信先エントリ 配布

Tiaccoond NIC Tiaccoon Controller アクセス制御エントリ src dst 許可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 src: labels: - app: client-b - role: web dst: labels: role: web - type: ALLOW priority: 100 src: labels: - app: client-b - role: web dst: labels: - app: server-a role: web 提案︓アクセス制御 ラベルベースの アクセス制御ポリシー をアクセス制御エントリ に変換して適⽤ 優先度の⾼い⼀番⾼い エントリのみ残す Slide: https://onoe.dev/ia202411 22

提案︓クラスタ外との通信 外部通信はTCP/IP通信であると仮定 外部のIPアドレス(またはFQDN)を⽤いてポリシーを書く Slide: https://onoe.dev/ia202411 23 アプリ Tiaccoond connect (1.2.3.4:443) Tiaccoon Controller 1.2.3.4:443 アプリ bind(:80) listen accept Tiaccoon Controller Tiaccoond 172.16.0.1:3001 1.2.3.4:60001 policy: - type: ALLOW priority: 10 src: external: 1.2.3.4 dst: labels: - app: server-a role: web policy: - type: ALLOW priority: 10 src: labels: - app: client-b - role: web dst: external: 1.2.3.4

提案︓クラスタ外との通信 インバウンド通信 Tiaccoondが代理作成し通信を受け付けるソケットに直接通信 Slide: https://onoe.dev/ia202411 24 通信先エントリ 仮想 ポート番号 トランス ポート⽅式 宛先物理 アドレス 80 IPv4 172.16.0.1:3001 80 UNIX(HostA) /var/b-web.sock アプリ bind(:80) listen accept Tiaccoon Controller policy: - type: ALLOW priority: 10 src: external: 1.2.3.4 dst: labels: - app: server-a role: web アクセス制御エントリ src dst 許可or拒否 1.2.3.4(external) 10.0.0.4 ALLOW Tiaccoond 172.16.0.1:3001 1.2.3.4:60001

提案︓クラスタ外との通信 アウトバウンド通信 外部のIPアドレス・ポート番号を⽤いてconnect呼び出し Slide: https://onoe.dev/ia202411 25 アプリ Tiaccoond connect (1.2.3.4:443) Tiaccoon Controller policy: - type: ALLOW priority: 10 src: labels: - app: client-b - role: web dst: external: 1.2.3.4 アクセス制御エントリ src dst 許可or拒否 10.0.0.1 1.2.3.4(external) ALLOW 1.2.3.4:443

議論︓コンテナ仮想ネットワークの代替 Isolation コンテナは専有のネットワークリソース(インターフェース・ポート空間) を持ち、同じホスト上の他コンテナと競合せずに通信できる Portability コンテナはホストに依存しない仮想アドレスを⽤いて 他コンテナと通信できる Controllability 管理者のみがネットワークポリシー(アクセス制御・レートリミット・QoS) を適⽤でき、コンテナは操作できない Slide: https://onoe.dev/ia202411 26

議論︓コンテナ仮想ネットワークの代替 Isolation コンテナは専有のネットワークリソース (インターフェース・ポート空間)を持ち、 同じホスト上の他コンテナと競合せずに 通信できる →ネットワークネームスペース分離に より専有リソースを持つ →ソケットはホスト上で作成されるが 置換後はコンテナがソケットを管理 Slide: https://onoe.dev/ia202411 27 Tiaccoond

Tiaccoond 10.0.0.2 Tiaccoond Tiaccoon Controller エントリ 更新 10.0.0.1 172.16.0.15:3001 /var/app-a.sock 172.16.0.16:4002 /var/app-a.sock 議論︓コンテナ仮想ネットワークの代替 Portability コンテナはホストに依存しない 仮想アドレスを⽤いて 他コンテナと通信できる →ホストに依存しない仮想アドレス でコンテナを識別して通信 →仮想アドレスと物理アドレスの 対応をTiaccoon Controllerが管理 Slide: https://onoe.dev/ia202411 28

議論︓コンテナ仮想ネットワークの代替 Controllability 管理者のみがネットワークポリシー (アクセス制御・レートリミット・QoS) を適⽤でき、コンテナは操作できない →アクセス制御ポリシーはTiaccoon Controllerを 通じて管理者のみが操作可能 →レートリミットやQoSは トランスポート⽅式ごとに適⽤し、 既存のコンテナ仮想ネットワークと同様に管理 Slide: https://onoe.dev/ia202411 29 Tiaccoond Tiaccoon Controller 管理者

議論︓通信性能 トランスポート⽅式の選択 UNIXやRDMAなど条件を満たした環境下で⾼速なトランスポート⽅ 式を利⽤することで、TCP/IPよりもスループット向上 コンテナネットワークスタックのバイパス ソケット置換によりホストのみでパケットを処理しスループット向上 ソケット作成処理 システムコールフック・トランスポート⽅式の選択・ソケット置換に よる追加の処理により通信開始時のレイテンシ悪化 →性能評価が必要 Slide: https://onoe.dev/ia202411 30

まとめ・今後の課題 Tiaccoon ソケットAPIで通信するトランスポート⽅式において 特定のトランスポート⽅式に依存しないアクセス制御・コンテナ通信を実現 仮想アドレスを引数とするシステムコールのフック ラベルベースのアクセス制御 ホスト上でのトランスポート⽅式選択・ソケット代理作成・置換 コンテナネットワークの要件(Isolation, Portability, Controllability)を満たす トランスポート⽅式の選択・コンテナネットワークスタックのバイパスによる スループット向上の⼀⽅で、ソケット作成処理による通信開始時のレイテンシ悪化 今後の課題 実装した上での性能評価 コンテナオーケストレータのない環境での利⽤可能性の評価 Slide: https://onoe.dev/ia202411 31