AI/MLのマルチテナント基盤を支えるコンテナ技術

AI/ML 基盤での Kubernetes、コンテナの利用が一般化する一方、GPU や MN-Core などの高価な計算資源を効率化するため、異なるユーザを同じ環境に収容するマルチテナント化の需要が高まっている。しかし、これを既存のコンテナ技術で実現する場合、セキュリティ等の新たな課題ももたらす。本講演では、この事業ニーズを背景にコンテナ技術そのものに焦点を当てる。マルチテナント環境の隔離性を実現するセキュリティ機能を、関連技術と共に解説する。さらに、Preferred Networks で提供している AI/ML ワークロード向けのクラウドサービス Preferred Computing Platform (PFCP) を題材に、2025年11月06日に発表された CVE-2025-31133 に対して最新のコンテナ技術を用いてどのように対応が可能かを説明する。これらの隔離技術が産業現場で果たす実践的な役割を論じる。後に、OSS コミュニティとの関わり方、その価値についても紹介する。
イベントサイト: https://sigos.ipsj.or.jp/event/comsys2025/

Transcript

1. AI/MLのマルチテナント基盤 を⽀えるコンテナ技術 Toru Komatsu(@utam0k) Preferred Networks, Inc. 2025年12月1日 ComSys 2025
2. 小松 享 / @utam0k • Preferred Networks, Inc. / エンジニア ◦ 社内/社外の AI/ML 基盤の構築と運用 ◦ 特にスケジューラやコンテナランタイム ◦ エンジニアリングマネージャー • OSS 活動 ◦ youki(CNCF Project) の作者 ◦ OCI Runtime Specification メンテナ ◦ Kubernetes SIG-Scheduling Reviewer ◦ containerd/runwasi Reviwer
3. AI/MLのマルチテナント基盤 を⽀えるコンテナ技術 Toru Komatsu(@utam0k) Preferred Networks, Inc. 2025年12月1日 ComSys 2025
4. 4 AI/ML 基盤の台頭 🤖 国内の AI システムの市場規模は 2029 年には4兆1,873億円に達する と予測されている[1] 推論ワークロードのホスト 📈 推論需要の急激な増加 • 学習ワークロードとは性質が異なる リソース効率 ⚡ 電⼒の問題 💸 経済性の問題 はじめに AI/ML 基盤に求められるもの [1]: IDC, “国内AI システム市場予測、2024 年~2029 年,” 2025 年 5 ⽉ https://openrouter.ai/rankings/marketing as of 2025/11/27 マルチテナンシによる 解決
5. 5 1. はじめに ◦ 題材となる PFN の AI/ML 基盤の紹介 2. コンテナ技術基礎 3. コンテナの脆弱性 ◦ 2025年11⽉にあった脆弱性の話 4. 安全に root 権限を与える ◦ コンテナ脆弱性への備え 5. 事業と OSS の関わり アジェンダ AI/ML 事業で⾼価なリソースを有効活⽤するための ⾼度なコンテナ技術の活⽤
6. 6 PFN の AI/ML 基盤 PFNの事業: AI技術のバリューチェーンを垂直統合 AIソリューション・製品 計算基盤 AI半導体 生成AI基盤モデル 様々な産業向けのAIソリューション・製品 MN-Core MN-Core 2 GPUクラスタ MN-3 (MN-Coreクラスタ) 大規模言語モデル MN-Core 次世代 MN-Core 2を 計算資源とした クラウドサービス 物質のエネルギー計算モデル PFP 生成AI（推論）向け MN-Core L1000 （2027年提供予定） PFNは、半導体、計算基盤、生成AI基盤モデル、ソリューション・製品まで、AI技術のバリューチェーン を垂直統合し、ソフトウェアとハードウェアを高度に融合することで、競争力の高い技術の開発および産 業応用を進めています。
7. 7 • PFN が構築、運⽤する AI‧ML ワークロード向けのクラウドサービス ◦ https://pfcomputing.com/ ◦ ユーザガイド: https://docs.pfcomputing.com/ • PFN のエンジニア‧リサーチャが使⽤する環境と同じものを提供 ◦ これまで社内向けに計算基盤を開発運⽤してきた経験を元に開発 • 強⼒な計算ボードと⾼速なネットワーク ◦ 独⾃開発したアクセラレータ MN-Core™ シリーズ等を提供 ◦ 深層学習に最適化された⾼速なネットワークで相互に接続 PFN の AI/ML 基盤 Preferred Computing Platform (PFCP)
8. 8 • 実験も学習も推論も ◦ 実験環境としてマネージドな JupyterLab を提供 ◦ 学習だけでなく、推論サーバの運⽤まで幅広いワークロードをサポート • 直接の Pod の利⽤も可能 • オープンソースを採⽤ ◦ コンテナ実⾏環境にKubernetes を採⽤ (Linux Foundation / CNCF) ◦ AI‧ML ワークロード向けに独⾃に拡張 • リソース使⽤状況の可視化 ◦ ワークロード状態を観測するためのモニタリングサービスも付随 PFN の AI/ML 基盤 Preferred Computing Platform (PFCP) 管理コンソール ワークロード・計算資源監視 対話型実験環境 分散学習・LLM 推論
9. 9 機械学習ジョブはバッチスケジューラでいい感じに動く • Kubernetes だと⾊々⼯夫が必要になる ユーザも Kubernetes や コンテナ に慣れる必要がある バッチスケジューラではなく、Kubernetes のいいところ • 実験の再現が容易 • 推論ワークロードを載せやすい ◦ そもそもが Web サービス のために作られたので オートスケール、モニタリング、サービス間接続 しやすい！ ◦ （スパコンに Jupyter や サーバ を乗せるのは⼤変そう...） • コミュニティが⼤きい ◦ LLM以降、バッチ利⽤についても OSS が⾊々増えてきている PFN の AI/ML 基盤 わざわざ Kubernetes で頑張る理由
10. 10 専有ノード: テナント専⽤ノード (+) ノードに他テナントのコンテナがいないため、セキュリティ的に安⼼ (-) ノードごとの⽉額単位で課⾦ 共有ノード: 複数のテナントが共有するノード (-) ノードに他テナントのコンテナがいるため、セキュリティが懸念 • コンテナを抜けられてホストに潜⼊できるとまずい (+) 利⽤に合わせて分単位で課⾦ (+) クラスタ全体の利⽤効率が⾼くなる PFN の AI/ML 基盤 PFCP のノードの種類 コンテナによる隔離の強化がより重要
11. 11 Kata Container • GPU を1枚しかサポートできていない ◦ 私の認識だと実装コストの都合 firecracker-microvm/firecracker/discussions/4845 • MN-Core のドライバ側の追加対応、検証が必要 gVisor • MN-Core のドライバ(proxy)側の追加対応、検証がかなり必要 KubeVirt • Pod ではなくなるのであらゆるものを再考しないといけなく、 つらい PFN の AI/ML 基盤 Kubernetes でコンテナ以外の選択肢
12. 12 コンテナ技術基礎
13. 13 コンテナ技術基礎
 コンテナができるまで Kubernetes Container Container Runtime High-Level Low-Level OCI Runtime Spec Container Runtime I nterface
14. 14 コンテナ技術基礎 コンテナ？ 
 • プロセス ≒ コンテナ
 ◦ 様々なリソースが隔離されたプロセス
 Processes Files Processes Files Processes
 Files OS 🐧
 Icon pack by Icons8 - https://icons8.com
15. 15 コンテナ技術基礎
 コンテナを支えるカーネル技術 / cgroups namespaces pivot_root capabilities Icon pack by Icons8 - https://icons8.com
16. 16 コンテナ技術基礎
 コンテナを支えるカーネル技術 / cgroups namespaces pivot_root capabilities Icon pack by Icons8 - https://icons8.com 今⽇簡単に説明する
17. 17 コンテナ技術基礎
 コンテナを支えるカーネル技術 / cgroups namespaces pivot_root capabilities Icon pack by Icons8 - https://icons8.com
18. 18 コンテナ技術基礎
 capabilities(7)
 root 権限の細分化
 • CAP_CHOWN • CAP_NET_ADMIN • CAP_SYS_ADMIN • CAP_BPF • などなど 
 e.g. eBPF
 マップの作成 = CAP_BPF 
 ネットワーク関連のプログラムのロード = CAP_BPF + CAP_NET_ADMIN
19. 19 コンテナ技術基礎
 コンテナを支えるカーネル技術 / cgroups namespaces pivot_root capability
20. 20 コンテナ技術基礎
 namespaces(7)
 様々なリソースを隔離
 ◦ PID namespace: プロセス群の隔離
 ◦ Mount namespace: マウントポイントリストの隔離
 ◦ UTS namespace: ホスト名などの隔離
 ◦ などなど

21. 21 コンテナ技術基礎 namespaces(7) - PID Namespace $ sleep 12345 & [1] 2476249 $ ps PID TTY TIME CMD 324304 pts/11 00:00:02 zsh 2476249 pts/11 00:00:00 sleep 2476331 pts/11 00:00:00 ps
22. 22 コンテナ技術基礎 namespaces(7) - PID Namespace $ sleep 12345 & [1] 2476249 $ ps PID TTY TIME CMD 324304 pts/11 00:00:02 zsh 2476249 pts/11 00:00:00 sleep 2476331 pts/11 00:00:00 ps $ sudo unshare --pid --fork --mount-proc
23. 23 コンテナ技術基礎 namespaces(7) - PID Namespace $ sleep 12345 & [1] 2476249 $ ps PID TTY TIME CMD 324304 pts/11 00:00:02 zsh 2476249 pts/11 00:00:00 sleep 2476331 pts/11 00:00:00 ps $ sudo unshare --pid --fork --mount-proc $ ps PID TTY TIME CMD 1 pts/6 00:00:00 zsh 3 pts/6 00:00:00 ps
24. 24 コンテナ技術基礎 namespaces(7) - PID Namespace $ sleep 12345 & [1] 2476249 $ ps PID TTY TIME CMD 324304 pts/11 00:00:02 zsh 2476249 pts/11 00:00:00 sleep 2476331 pts/11 00:00:00 ps $ sudo unshare --pid --fork --mount-proc $ ps PID TTY TIME CMD 1 pts/6 00:00:00 zsh 3 pts/6 00:00:00 ps
25. 25 コンテナ技術基礎
 コンテナを支えるカーネル技術 / cgroups namespaces pivot_root capabilities Icon pack by Icons8 - https://icons8.com
26. 26 コンテナの脆弱性
27. 27 専有ノード: テナント専⽤ノード (+) ノードに他テナントのコンテナがいないため、セキュリティ的に安⼼ (-) ノードごとの⽉額単位で課⾦ 共有ノード: 複数のテナントが共有するノード (-) ノードに他テナントのコンテナがいるため、セキュリティが懸念 • コンテナを抜けられてホストに潜⼊できるとまずい (+) 利⽤に合わせて分単位で課⾦ (+) クラスタ全体の利⽤効率が⾼くなる PFN の AI/ML 基盤 PFCP のノードの種類 コンテナによる隔離の強化がより重要
28. 小松 享 / @utam0k • Preferred Networks, Inc. / エンジニア ◦ 社内/社外の AI/ML 基盤の構築と運用 ◦ 特にスケジューラやコンテナランタイム • エンジニアリングマネージャー • OSS 活動 ◦ youki の作者 ◦ OCI Runtime Specification メンテナ ◦ Kubernetes SIG-Scheduling Reviewer ◦ containerd/runwasi Reviwer
29. 29 コンテナの脆弱性 2025年11⽉7⽇ CVE-2025-31133 / 7.3 High(CVSS v4) • maskedPaths 実装における競合状態 CVE-2025-52565 / 7.3 High(CVSS v4) • /dev/console のマウント初期化時の競合 CVE-2025-52881 / 7.3 High(CVSS v4) • 共有マウントを利⽤した /proc への書き込みリダイレクトと LSM 回避
30. 30 コンテナの脆弱性 2025年11⽉7⽇ CVE-2025-31133 / 7.3 High(CVSS v4) • maskedPaths 実装における競合状態 CVE-2025-52565 / 7.3 High(CVSS v4) • /dev/console のマウント初期化時の競合 CVE-2025-52881 / 7.3 High(CVSS v4) • 共有マウントを利⽤した /proc への書き込みリダイレクトと LSM 回避
31. 31 コンテナの脆弱性 - CVE-2025-31133 maskedPaths maskedPaths: コンテナ内で⾒せたくないパスをマスクする
32. 32 コンテナの脆弱性 - CVE-2025-31133 実際の runc のコード https://github.com/opencontainers/runc/blob/v1.3.2/libcontainer/rootfs_linux.go
33. 33 コンテナの脆弱性 - CVE-2025-31133 /dev/null を⽤いた maskedPaths の実装 /dev/null デバイスを⽤いたファイルのマスク → 読み込み: EOF / 書き込み: 破棄
34. 34 コンテナの脆弱性 - CVE-2025-31133 /dev/null の安全 /dev/null デバイスを⽤いたファイルのマスク → 読み込み: EOF / 書き込み: 破棄 本当に安全？
35. 35 コンテナの脆弱性 - CVE-2025-31133 /dev/null の安全 /dev/null デバイスを⽤いたファイルのマスク → 読み込み: EOF / 書き込み: 破棄 本当に期待している /dev/null?
36. 36 コンテナの脆弱性 - CVE-2025-31133 /dev/null の検証
37. 37 コンテナの脆弱性 - CVE-2025-31133 /dev/null の安全 本当にこのときに期待 している/dev/null?
38. 38 コンテナの脆弱性 - CVE-2025-31133 /dev/null の安全
39. 39 コンテナの脆弱性 - CVE-2025-31133 TOCTOU 😈 検証後に差し込まれる
40. 40 コンテナの脆弱性 - CVE-2025-31133 実際の runc のコード https://github.com/opencontainers/runc/blob/v1.3.2/libcontainer/rootfs_linux.go
41. 41 コンテナの脆弱性 - CVE-2025-31133 実際の runc のコード https://github.com/opencontainers/runc/blob/v1.3.2/libcontainer/rootfs_linux.go 本当に /dev/null ? どこの /dev/null ?
42. 42 コンテナの脆弱性 - CVE-2025-31133 実際の runc のコード https://github.com/opencontainers/runc/blob/v1.3.2/libcontainer/rootfs_linux.go コンテナ内の /dev/null いろいろ仕掛け が可能そう
43. 43 コンテナの脆弱性 - CVE-2025-31133 TOCTOU 😈
44. 44 コンテナの脆弱性 - CVE-2025-31133 パッチ 根本的な問題 • コンテナの起動プロセスの権限が root である • mount(2) に検証済みの fd を渡すことができない 解決策 • move_mount(2) の利⽤ ◦ linux カーネル 5.3 から利⽤可能 • /proc/thread-self/fd/N を利⽤ ◦ 古いカーネル⽤ https://github.com/opencontainers/runc/blob/v1.3.2/libcontainer/rootfs_linux.go 3つの CVE のパッチ
45. 45 コンテナの脆弱性 他にも過去の脆弱性の話 CVE-2024-21626: Leaky Vessels, 8.6 High (CVSS v3.1) • runc の初期化中にホスト側の重要な FD がコンテナにリーク CVE-2019-5736: runcバイナリ上書き, 8.6 High (CVSS v3.1) • /proc/self/exe を経由してホスト上の runc バイナリ⾃体を悪意のある コードで上書きしてしまう脆弱性 コンテナがホストの root で動いてしまうのがつらい
46. 46 安全に root 権限を与える
47. 47 安全に root 権限を与える PFCP のノードの種類 専有ノード: テナント専⽤ノード (+) ノードに他テナントのコンテナがいないため、セキュリティ的に安⼼ (-) ノードごとの⽉額単位で課⾦ 共有ノード: 複数のテナントが共有するノード (-) ノードに他テナントのコンテナがいるため、セキュリティが懸念 • コンテナを抜けられてホストに潜⼊できるとまずい (+) 利⽤に合わせて分単位で課⾦ (+) クラスタ全体の利⽤効率が⾼くなる
48. 48 root ユーザー禁⽌ (+) コンテナを抜けられてもすぐに root ユーザーにはなれない (-) root ユーザーが使えないため apt install などできない root ユーザー許容 (-) コンテナを抜けられたときにホストの root ユーザーとなる ◦ 他テナントのコンテナに潜⼊されるリスク (+) apt install など可能に 安全に root 権限を与える コンテナセキュリティ強化と利便性 root を許可しつつ、安全にしたい
49. 49 • kubernetes/enhancements#127(Beta), Oct 11, 2016 ~ • コンテナ内で安全に UID: 0(≒ root) を使える 安全に root 権限を与える KEP-127: Support User Namespaces
50. 50 安全に root 権限を与える User Namespace With a Pod apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx securityContext: runAsUser: 1000
51. 51 安全に root 権限を与える User Namespace With a Pod apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx securityContext: runAsUser: 1000 => mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
52. 52 安全に root 権限を与える User Namespace With a Pod apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx $ crictl inspect $cid | grep pid "pid": 55770, $ ps -o uid,comm -p 55770 UID COMMAND 0 nginx Node Manifest
53. 53 安全に root 権限を与える User Namespace With a Pod apiVersion: v1 kind: Pod metadata: name: cndw2024 spec: hostUsers: false containers: - name: shell command: ["sleep", "infinity"] image: debian
54. 54 安全に root 権限を与える User Namespace With a Pod apiVersion: v1 kind: Pod metadata: name: nginx spec: hostUsers: false containers: - name: nginx image: nginx $ crictl inspect $cid | grep pid "pid": 56560, $ ps -o uid,comm -p 56560 UID COMMAND 631373824 nginx Node Manifest
55. 55 安全に root 権限を与える / User Namespace User Namespace With a Pod apiVersion: v1 kind: Pod metadata: name: nginx spec: hostUsers: false containers: - name: nginx image: nginx $ crictl inspect $cid | grep pid "pid": 56560, $ ps -o uid,comm -p 56560 UID COMMAND 631373824 nginx Node Manifest 高度に発達したコンテナは 魔術と見分けがつかない Any sufficiently advanced container is indistinguishable from magic
56. 56 From user_namespaces(7): 安全に root 権限を与える / User Namespace User Namespace とは？ User namespaces isolate security-related identifiers and attributes, in particular, user IDs and group IDs, the root directory, keys, and capabilities. A process's user and group IDs can be different inside and outside a user namespace. In particular, a process can have a normal unprivileged user ID outside a user namespace while at the same time having a user ID of 0 inside the namespace; in other words, the process has full privileges for operations inside the user namespace, but is unprivileged for operations outside the namespace.
57. 57 From user_namespaces(7): 安全に root 権限を与える / User Namespace User Namespace とは？ User namespaces isolate security-related identifiers and attributes, in particular, user IDs and group IDs, the root directory, keys, and capabilities. A process's user and group IDs can be different inside and outside a user namespace. In particular, a process can have a normal unprivileged user ID outside a user namespace while at the same time having a user ID of 0 inside the namespace; in other words, the process has full privileges for operations inside the user namespace, but is unprivileged for operations outside the namespace. 🤔
58. 58 • Linux Namespaces の 1種類 ◦ ⾮特権ユーザーから分離できる • 特に UID/GID をホストの User NS から分離する ◦ ホストの User NS からマッピングが可能 安全に root 権限を与える / User Namespace User Namespace とは？
59. 59 安全に root 権限を与える / User Namespace UID のマッピング Init User NS 0 … 999 1000 … 1999 2000 … 2999 3000 … 3999 Container 1 User NS 0 … 999 Container 2 User NS 0 … 999 1000 …. 1999 Host Init User NS 0 … 999 1000 … 1999 2000 … 2999 3000 … 3999 Init User NS 0 … 999 Init User NS 0 … 999 1000 …. 1999 Host User Namespace なしのUIDs User Namespace ありの UIDs コンテナ1 コンテナ2
60. 60 安全に root 権限を与える / User Namespace コマンド $ whoami utam0k $ id uid=1000(utam0k) gid=1000(utam0k) groups=1000(utam0k) $ unshare --user
61. 61 安全に root 権限を与える / User Namespace コマンド $ whoami utam0k $ id uid=1000(utam0k) gid=1000(utam0k) groups=1000(utam0k) $ unshare --user $ whoami nobody $ id uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup) Init User NS Container User NS
62. 62 User Namespace とは？ UID / GID Mapping 0
 0
1
 1000
 65536
 100000
 165535
 Host UIDs Container UIDs $ cat /proc/37/uid_map 0 1000 　 1 1 100000　 65536 # 　ID-child-ns 　ID-parent-ns length
63. 63 newuidmap: User NS の UID のマッピングを⾏ってくれる 4つの引数 ◦ pid ターゲットのプロセスID ◦ uid ⼦の UserNS のスタートのUID ◦ loweruid 親の UserNS のスタートのUID ◦ count マッピングする UID の⻑さ 安全に root 権限を与える / User Namespace UID / GID Mapping $ newuidmap 37 0 1000 1 $ echo $? 0
64. 64 安全に root 権限を与える / User Namespace UID / GID Mapping $ unshare --user $ id -u 65534 $ cat /proc/$$/uid_map $ echo $$ 37 $ newuidmap 37 0 1000 1 $ ps -o uid,comm -p 37 UID COMMAND 1000 zsh $ cat /proc/$$/uid_map 0 1000 1 $ id -u 0 Container NS Init User NS ① ② ③
65. 65 安全に root 権限を与える / User Namespace UID / GID Mapping Container NS Init User NS ① $ unshare --user $ id -u 65534 $ cat /proc/$$/uid_map $ echo $$ 37
66. 66 安全に root 権限を与える / User Namespace UID / GID Mapping Container NS Init User NS ① ② $ unshare --user $ id -u 65534 $ cat /proc/$$/uid_map $ echo $$ 37 $ newuidmap 37 0 1000 1 $ ps -o uid,comm -p 37 UID COMMAND 1000 zsh
67. 67 安全に root 権限を与える / User Namespace UID / GID Mapping $ unshare --user $ id -u 65534 $ cat /proc/$$/uid_map $ echo $$ 37 $ cat /proc/$$/uid_map 0 1000 1 $ id -u 0 Container NS Init User NS ① ② ③ $ newuidmap 37 0 1000 1 $ ps -o uid,comm -p 37 UID COMMAND 1000 zsh
68. 68 安全に root 権限を与える / User Namespace UID / GID Mapping - Podman を使った例 $ podman run --name userns -it --rm --userns="" docker.io/library/busybox / # id uid=0(root) gid=0(root) groups=10(wheel) $ PID=$(podman inspect userns | jq .[0].State.Pid) $ cat /proc/$PID/uid_map 0 1000 1 1 100000 65536 Init User NS Podman NS ① ②
69. 69 Point: コンテナの隔離が抜けられてもホストでは⼀般ユーザー CVE-2025-31133: maskedPaths 実装における競合状態 CVE-2019-5736: ホストの runc バイナリをコンテナ側から書き換え可能 ✔ コンテナ側の uid: 0 はホストの uid: 0 ではないので権限不⾜となる 安全に root 権限を与える / User Namespace CVEの事例紹介と有効な理由 From: https://kubernetes.io/blog/2019/02/11/runc-and-cve-2019-5736/
70. 70 真の root = init_user_ns の UID: 0 カーネル側では適宜真の root かチェックしている 安全に root 権限を与える / User Namespace なぜ安全なのかもう少し深掘り https://elixir.bootlin.com/linux/v6.12/source/kernel/capability.c#L424-L437 /** * capable - Determine if the current task has a superior capability in effect * @cap: The capability to be tested for … */ bool capable(int cap) { return ns_capable(&init_user_ns, cap); }
71. 71 User NS の UID/GID のマッピングはあくまでもプロセスのおはなし ◦ ファイルは...？ 安全に root 権限を与える / User Namespace ファイルの所有者 Processes Files Processes Files Processes
 Files OS 🐧
 ここはおっけー Icon pack by Icons8 - https://icons8.com
72. 72 User NS の UID/GID のマッピングはあくまでもプロセスのおはなし ◦ ファイルは...？ 安全に root 権限を与える / User Namespace ファイルの所有者 Processes Files Processes Files Processes
 Files OS 🐧
 コンテナのイメージは様々なユーザー が所有しているファイルなどある Icon pack by Icons8 - https://icons8.com
73. 73 安全に root 権限を与える / User Namespace Permission Denied $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt utam0k: 1000 pfn: 1001
74. 74 安全に root 権限を与える / User Namespace Permission Denied $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ unshare --user --map-root-user $ cat /proc/$$/uid_map 0 1000 1 utam0k: 1000 pfn: 1001 コンテナの 0 をホスト 1000 に 長さ 1 でマッピングされている utam0k(ホスト) ↔ root(コンテナ) 実行ユーザー(utam0k) を root ユーザーにマッピング
75. 75 安全に root 権限を与える / User Namespace Permission Denied $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ unshare --user --map-root-user $ cat /proc/$$/uid_map 0 1000 1 $ ls -l drwxrwxr-x 2 nobody nogroup 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 root root 10 Nov 9 11:45 utam0k.txt utam0k: 1000 pfn: 1001
76. 76 安全に root 権限を与える / User Namespace Permission Denied $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ unshare --user --map-root-user $ cat /proc/$$/uid_map 0 1000 1 $ ls -l drwxrwxr-x 2 nobody nogroup 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 root root 10 Nov 9 11:45 utam0k.txt $ echo "test" | tee -a pfn/pfn.txt tee: pfn/pfn.txt: Permission denied test $ echo "test" | tee -a utam0k.txt test utam0k: 1000 pfn: 1001
77. 77 安全に root 権限を与える / id-mapped mount id-mapped mount とは？ Init User NS Container User NS UID/GID のマッピング by FS UID 0 UID 1000 UID 1000 UID 2000 ・・・ ・・・ Icon pack by Icons8 - https://icons8.com
78. 78 安全に root 権限を与える / id-mapped mount コマンド $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 27 08:26 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ sudo mount -m --bind --map-users 1001:1000:1 $(pwd)/pfn $(pwd)/mnt utam0k: 1000 pfn: 1001 1001(pfn) を 1000(utam0k) に 長さ 1 でマッピング 1001(pfn) → 1000(utam0k)
79. 79 安全に root 権限を与える / id-mapped mount コマンド $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 27 08:26 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ sudo mount -m --bind --map-users 1001:1000:1 $(pwd)/pfn $(pwd)/mnt $ ls -l drwxrwxr-x 2 utam0k nogroup 4096 Nov 10 12:03 mnt/ drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt utam0k: 1000 pfn: 1001
80. 80 安全に root 権限を与える / id-mapped mount コマンド - User Namespace と組み合わせる $ sudo mount -m --bind --map-users 1001:1000:1 $(pwd)/pfn $(pwd)/mnt $ ls -l drwxrwxr-x 2 utam0k nogroup 4096 Nov 10 12:03 mnt/ drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt utam0k: 1000 pfn: 1001
81. 81 安全に root 権限を与える / id-mapped mount コマンド - User Namespace と組み合わせる $ sudo mount -m --bind --map-users 1001:1000:1 $(pwd)/pfn $(pwd)/mnt $ ls -l drwxrwxr-x 2 utam0k nogroup 4096 Nov 10 12:03 mnt/ drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ unshare --user --map-root-user $ echo "test" | tee -a mnt/pfn.txt test $ cat pfn/pfn.txt pfn test utam0k: 1000 pfn: 1001
82. 82 ✓ User Namespace プロセスの UID/GID の変換を担当 ✓ id-mapped mount ファイルシステムレイヤでの UID/GID の変換を担当 安全に root 権限を与える 安全にコンテナに root を与える要素技術まとめ Processes Files Processes Files Processes
 Files OS 🐧
 User Namespace id-mapped mount Icon pack by Icons8 - https://icons8.com
83. 83 安全に root 権限を与える / Kubernetes からの利⽤ コンテナ側からの視点 $ kubectl apply -f https://k8s.io/examples/pods/user-namespaces-stateless.yaml pod/userns created
84. 84 安全に root 権限を与える / Kubernetes からの利⽤ コンテナ側からの視点 $ kubectl apply -f https://k8s.io/examples/pods/user-namespaces-stateless.yaml pod/userns created $ kubectl exec userns -- lsfd -p 1 | head -n 2 COMMAND PID USER ASSOC MODE TYPE SOURCE MNTID INODE NAME sleep 1 root exe --- REG overlay 0 8393115 /usr/bin/sleep $ kubectl exec userns -- id uid=0(root) gid=0(root) groups=0(root)
85. 85 安全に root 権限を与える / Kubernetes からの利⽤ コンテナ側からの視点 $ kubectl apply -f https://k8s.io/examples/pods/user-namespaces-stateless.yaml pod/userns created $ kubectl exec userns -- lsfd -p 1 | head -n 2 COMMAND PID USER ASSOC MODE TYPE SOURCE MNTID INODE NAME sleep 1 root exe --- REG overlay 0 8393115 /usr/bin/sleep $ kubectl exec userns -- id uid=0(root) gid=0(root) groups=0(root) $ kubectl exec userns -- cat /proc/self/uid_map 0 700448768 65536 # 　ID-child-ns 　ID-parent-ns length
86. 86 安全に root 権限を与える / Kubernetes からの利⽤ ノード側からの視点 $ minikube ssh $ sudo crictl ps | grep userns 464c62f753d43 63ba939a68fde 5 seconds ago Running ... $ sudo crictl inspect 464c62f753d43 | grep pid "pid": 3574,
87. 87 安全に root 権限を与える / Kubernetes からの利⽤ ノード側からの視点 $ minikube ssh $ sudo crictl ps | grep userns 464c62f753d43 63ba939a68fde 5 seconds ago Running ... $ sudo crictl inspect 464c62f753d43 | grep pid "pid": 3574, $ ps -o uid,comm -p 3574 UID COMMAND 700448768 sleep
88. 88 id-mapped mount が⾮対応なファイルシステムがある man の mount_setattr(2) の Notes セクションに対応済み⼀覧がある ✓ xfs(5) (since Linux 5.12) ✓ ext4(5) (since Linux 5.12) ✓ btrfs(5) (since Linux 5.15) ✓ overlayfs (ID-mapped lower and upper layers supported since Linux 5.19) ✓ cephfs (since Linux 6.7) NFS が⾮対応 で困った... 😭 → RWX なストレージを提供できていない 安全に root 権限を与える 直⾯した課題
89. 89 ➔ NFS が id-mapped mount ⾮対応 ◦ NFS を必要とするコンテナの起動に失敗する ➔ id-mapped mount がないとどうなるか？ ◦ 起動は成功する ◦ NFS で UID/GID がおかしくなり、消えないファイルが誕⽣する ➔ そもそも PFCP の NFS の UID/GID は必要？ ◦ PFCP では各テナントは Kubernetes の Namespace で区切られ ているので UID/GID での制御は不要 ➔ 誰が書き込んでいるかは考えなくよい(all_squash) 安全に root 権限を与える / 直⾯した課題 問題を整理
90. 90 安全に root 権限を与える / 直⾯した課題 id-mapped mount をスキップさせる Kubernetes Container Container Runtime High-Level Low-Level OCI Runtime Spec Container Runtime I nterface
91. 91 安全に root 権限を与える / 直⾯した課題 id-mapped mount をスキップさせる
92. 92 安全に root 権限を与える / 直⾯した課題 id-mapped mount をスキップさせる ここでファイルシステムの種類ごとに id-mapped mount のスキップの制御はできない😢
93. 93 安全に root 権限を与える / 直⾯した課題 id-mapped mount をスキップさせる NEW
94. 94 安全に root 権限を与える / NRI NRI(Node Resource Interface) Low-Level に渡る情報を加⼯、検証できる Kubernetes Container Container Runtime High-Level Low-Level OCI Runtime Spec Container Runtime I nterface
95. 95 • containerd/nri • Kubecon + CNC 2025 でもいくつか発表 • Pod とコンテナのライフサイクルに合わせて プラグインがフックされる ◦ e.g., 作成、消去、停⽌ • プラグインでは検証やコンテナの加⼯が可能 ◦ 加⼯できるフィールド例: ▪ Linux namespaces ▪ memory の swap limit ▪ CPU の quota や period • Protobuf ベースの NRI Plugin プロトコルでコ ンテナランタイム側とやりとり 安全に root 権限を与える / NRI NRI(Node Resource Interface) https://github.com/containerd/nri
96. 96 安全に root 権限を与える / NRI NRI Plugin の実装例
97. 97 安全に root 権限を与える / NRI id-mapped mount をスキップさせる コンテナの加工をプラグインの ようにできるコンテナランタイ ムの新機能 NFS の時だけ id-mapped mount をスキップ NEW
98. 98 ここがすごい！ • 標準化されているのでコンテナランタイムへの依存がない • プラグインで差し込めるので簡単にコンテナランタイムに機能追加可能 ◦ 最先端の機能もお試しでプラグインとしてすぐに取り込める • NRI のプラグインでは Pod のアノテーション情報も⾒える • WebAssembly サポートがある ここが注意！ • まだまだ新しい機能で情報は少ない • 加⼯できない OCI Runtime のフィールドもある いままではどうしていたのか？ • OCI Runtime の Hooks を使って差し込む • Low-Level コンテナランタイムをラップする 安全に root 権限を与える / NRI id-mapped mount をスキップさせる
99. 99 ❗やりたいこと • (コンテナ内では) root だが、(ホストでは) root ではない 🛡 コンテナ内で安全に root を与える • User Namespace • id-mapped mount ⚠ 制限 • id-mapped mount の制約により NFS が利⽤できない 💡 解決⽅法 • NRIを⽤いたコンテナランタイムの拡張 安全に root 権限を与える 過去の多くのコンテナ脆弱性を防ぐ
100. 100 産業と OSS の関わり
101. 101 産業と OSS の関わり コンテナでの新しい技術の⽣まれ⽅ Kubernetes Container Container Runtime High-Level Low-Level OCI Runtime Spec Container Runtime I nterface
102. 102 産業と OSS の関わり コンテナでの新しい技術の⽣まれ⽅ User Namespace の機能が⽣まれるには？ 1. Kubernetes 側で話を進める 2. OCI Runtime Spec 側で話を進める 3. Low Level コンテナランタイム 側で実装 4. High Level コンテナランタイム側で実装 5. Kubernetes で実装
103. 103 産業と OSS の関わり コンテナでの新しい技術の⽣まれ⽅ Kubernetes Container Container Runtime High-Level Low-Level OCI Runtime Spec Container Runtime I nterface
104. 104 産業と OSS の関わり 仕様策定のメンテナであること ✓ 技術が⽣まれるところへ参加できる ◦ ⾃分たちで使いたいケースも仕様策定段階で話ができる ▪ 実装フェーズでひっくり返すのは⼤変 ✓ 機能をいち早く社会に届ける⼿助けができる ◦ ⾃分もマージやリリースを⾏う権限を持つ責任 ✓ 持続可能な OSS の構築 ◦ 活発な OSS にすることでアカデミアからの注⽬を獲得し、新 しい技術が作られる ✓ F2F での会話への参加機会の増加 ◦ オフラインで会うことの重要性は増している
105. 105 産業と OSS の関わり 参考: オープンソースソフトウェアへの解像度 https://wakate.org/2025/08/18/58th-general/
106. 106 xz バックドア事件(2024) • メンテナがバックドアを仕掛ける • おそらく OSS 界隈での氷⼭の⼀⾓ 背景 • メンテナは 2 年もの歳⽉を費やして信頼を構築 ◦ ⾝元が明らかでない中、メンテナ権限が付与された • xz の開発が停滞していた 産業と OSS の関わり OSS のセキュリティリスク
107. 107 メンテナとして関わる ✓ ガバナンスへの参加 ✓ 信頼できる開発者として OSS に参加し、監視する ◦ ⾃分の⾝は⾃分で守る ✓ 狙われるリスクのトレンドを知る ◦ Closed なセキュリティ関連のやりとりから学ぶ ▪ 攻撃者、守る側の両⽅の視点をもつ ▪ トレンドを知ることで有効な対策もわかる 産業と OSS の関わり OSS のセキュリティリスク
108. 108 産業と OSS の関わり 参考: なぜオープンソースソフトウェアにコントリビュートすべきなのか https://wakate.org/2024/08/13/57th-general/
109. 109 まとめ 🤖 AI/ML 基盤に求められるもの ◦ ⾼価な計算資源の有効活⽤ → マルチテナンシ 📦 コンテナ脆弱性 ◦ CVE-2025-31133: maskedPaths 実装における競合状態 ◦ コンテナがホストの root で動いてしまうのがつらい 🔐 安全に root 権限を与える ◦ User Namespace: プロセスの UID/GID のマッピング ◦ id-mapped monut: ファイルの UID/GID のマッピング ◦ NRI(Node Resource Interface): コンテナランタイムの拡張 🤝 産業と OSS の関わり ◦ 技術が⽣まれるところに⼊る ◦ OSS のセキュリティリスク
110. Making the real world computable