【CNDW2024】コンテナをより安全にするUser NamespaceがもたらすKubernetesの進化

CloudNative Days Winter 2024において、Preferred Networksの小松とおる氏が「次のコンテナセキュリティの時代 - User Namespace With a Pod」と題したセッションを実施した。セッションでは、コンテナセキュリティの重要性と、その向上を目的とした「User Namespace With a Pod」の技術的背景や実装方法について詳しく解説された。

コンテナの進化とともに求められる新たなセキュリティ対策

小松氏はPreferred Networksにおいてオンプレミスの機械学習基盤の開発・運用を担当している。オープンソース活動にも積極的に関与し、コンテナ技術の発展にも携わっている。「コンテナ技術の進化とともに、セキュリティの重要性がますます高まっています。今回はその中でもとくにUser Namespaceに焦点を当てて解説します」と語り、セッションのテーマを明確にした。

次にUser Namespace With a Podの基本概念を説明した。この機能はKubernetes Enhancement Proposal（KEP）#127として2016年に提案され、現在ベータ版として提供されているが、今後のGAに向けた課題として、特定のコンテナランタイムとの互換性やIDマッピングの取り扱いに関する議論が続いている。

従来のコンテナ環境では、特権ユーザー（UID:0、いわゆるrootユーザー）をコンテナ内で使用すると、万一のブレークアウト時にホストのroot権限を奪われるリスクがあった。このリスクを軽減するために、User Namespaceを利用することでコンテナ内のrootユーザーをホストの一般ユーザーにマッピングし、安全性を確保する仕組みだ。

通常のPodでは、ここでセキュリティを考慮して特定のユーザーIDで動作させようとすると、権限の問題でエラーが発生するケースがある。この問題に対し、User Namespaceを適用すると、Podの設定を変更するだけでコンテナ内のrootユーザーがホストの一般ユーザーとして扱われるようになり、特権昇格を防ぐことができる。「この機能を活用すれば、コンテナが制限を超えてもホストのroot権限を得ることはできません。つまり、コンテナセキュリティのレイヤーを1つ増やすことができます」と小松氏は解説した。

またUser Namespace With a Podの検証環境についても言及した。本機能を試すために、小松氏はminikube環境を構築し、その手順を公開している。「皆さんが試せるように、minikube上で簡単に動かせる環境を用意しました。ぜひ試してください」と、GitHubリポジトリのリンクも紹介した。

検証環境

コンテナの分離技術とUser Namespaceの役割

コンテナ技術の根幹には、Linuxのさまざまな機能が関わっている。その中でも、コンテナの分離を実現するために重要な技術が「namespaces」と「capabilities」である。小松氏は、これらの技術の基礎を説明しながら、User Namespaceがどのようにコンテナのセキュリティ向上に貢献するのかを詳しく解説した。

コンテナを支えるカーネル技術

まずnamespacesの概念について説明がなされた。namespacesとは、Linuxカーネルの機能の一つであり、プロセスがアクセスできるリソースを分離する仕組みだ。代表的なものとして、PID namespace（プロセスIDの分離）、Mount namespace（ファイルシステムの分離）、UTS namespace（ホスト名の分離）などがあるが、今回とくに焦点を当てたのはUser Namespaceだ。「User Namespaceを使うことで、コンテナのroot権限を制限し、より安全な環境を作ることができます」と小松氏は語った。

小松氏は、スライド上に「高度に発達したコンテナは魔術と見分けがつかない」と引用し、コンテナ技術が進化することで、内部の仕組みがより難解になり、ユーザーにはまるで魔法のように見えることを指摘した。

次にUser Namespaceの具体的な仕組みを説明した。User Namespaceを利用すると、コンテナ内でroot権限を持つプロセスであっても、ホスト側では非特権ユーザーとして扱われる。これは、UID/GIDのマッピング機能によって実現されている。つまりコンテナ内でUID:0（root）として動作するプロセスが、ホスト上では一般ユーザーのUIDとして変換されるため、仮にコンテナが突破されても、ホストの管理者権限を奪われることはないというわけだ。

この仕組みをより直感的に理解するために、User NamespaceのUIDマッピングの具体例が示された。例えば、コンテナ内のUID:0をホストのUID:1000にマッピングすることで、コンテナ内では管理者権限を保持しながらも、ホスト側では一般ユーザーとして認識される。このためコンテナのセキュリティを強化する手段として非常に有効である。

さらにUser Namespaceと関連するもう一つの重要な技術として「id-mapped mount」も紹介した。User NamespaceではプロセスのUID/GIDはマッピングできるが、ファイルの所有者情報はそのままのため、権限の不整合が発生することがある。とくにホスト上のNFSマウント環境やホストボリュームを利用する場合、アクセス権限のエラーが生じやすい。この問題を解決するのがid-mapped mountであり、ファイルのUID/GIDを適切に変換することで、コンテナ内のファイル所有者情報を管理できる。

これを活用することで、「コンテナのUID/GIDの分離」だけでなく、「ファイルの所有者情報の分離」も実現でき、より安全なコンテナ環境が構築できる。小松氏は「User Namespaceとid-mapped mountを組み合わせることで、より強固なコンテナ分離が可能になる」と強調した。

Kubernetes環境でのUser Namespaceの活用とコンテナセキュリティの未来

この後、User Namespaceの基本概念を踏まえ、Kubernetesにおいてこれを適用する方法が解説された。従来のコンテナ環境では、Pod内のユーザーがホストのユーザーと直接対応するため、特権昇格のリスクがあった。しかしUser Namespace With a Podを利用することで、この問題を解決できる。

KubernetesでUser Namespaceを有効化するには、Podの設定においてhostUsers:falseを指定する。これにより、Pod内のUID/GIDがホストと分離され、コンテナブレークアウトのリスクが大幅に低減される。「Podの設定を一行追加するだけで安全性が向上するのは大きなメリットです」と小松氏は強調した。

Kubelet → High-Level Container Runtime

さらにid-mapped mountと組み合わせることで、コンテナ内のファイルシステムの所有者情報も適切に管理できる。

こうしてUser Namespace With a Podを導入することで、Kubernetes環境におけるセキュリティリスクを大幅に低減できる。とくに従来のコンテナに存在していた特権昇格のリスクを軽減し、Kubernetes環境においてより安全な運用を可能にする技術として注目されている。

この機能を活用することで、Pod内のプロセスはホストの特権ユーザーとは切り離され、ブレークアウト攻撃のリスクが大幅に低減される。さらにid-mapped mountを組み合わせることで、ファイルシステムの安全性も確保できる。

コンテナ技術が進化する中で、セキュリティ対策もまた進化しなければならない。User Namespace With a Podは、その一歩となる技術と言える。今後、Kubernetesの標準機能としてUser Namespace With a Podが定着すれば、コンテナブレークアウトのリスクを大幅に減少させることができるだろう。