Kubernetes v1.33、ユーザー名前空間をデフォルトで有効化し分離性を強化

2025年4月のKubernetes Blogの投稿にて、メンテナはKubernetes v1.33でLinuxユーザー名前空間のサポートがデフォルトで有効になることを発表しました。この変更により、基盤となるインフラストラクチャが特定のカーネルおよびランタイム要件を満たしていれば、機能フラグを設定することなく、Podはより強力な分離性を適用できます。

何が起きたのか

今回のリリース以前は、Kubernetesでユーザー名前空間を使用するには、明示的な機能ゲートを有効にし、複雑な設定手順を踏む必要がありました。バージョン1.33では、この機能が安定版（stable）となり、デフォルトで有効になります。スタックの要件を満たしている場合、ユーザーはPod仕様を通じて簡単に利用を開始できます。これは、最小権限セキュリティモデルの実装に伴う摩擦を減らし、「デフォルトで安全」なコンテナオーケストレーションへの重要な一歩です。

発表では、これがLinux専用の機能であることが明確にされています。カーネルレベルでユーザー識別子を分離する「Linuxユーザー名前空間」と、リソースのための論理的なクラスタである「Kubernetes名前空間」を区別しています。本アップデートは、コンテナ内でrootとして実行されるプロセスがホストノード上でroot権限を持たないようにすることで、コンテナエスケープに関連するリスクを軽減することを目的としています。

仕組み

Linuxユーザー名前空間は、コンテナ内のプロセスのユーザーID（UID）とグループID（GID）を、ホストシステム上のそれらから分離します。Podがユーザー名前空間を使用する場合、コンテナ内のUIDとGIDは、ホスト上の異なる非特権的な識別子にマッピングされます。例えば、コンテナ内でUID 0（root）として実行されるプロセスは、ホスト上ではUID 100000にマッピングされる可能性があります。このマッピングにより、仮にコンテナプロセスが境界を越えてエスケープした場合でも、特権ユーザーとしてホストファイルを変更したり、他のホストプロセスとやり取りしたりするための権限を持たなくなります。

このメカニズムは、マウントされたファイルシステムへのアクセス時にUID/GIDマッピングを適用するLinuxカーネル機能である「idmap mounts」に大きく依存しています。idmap mountsにより、各Podはボリューム上のファイル所有権を手動で変更（chown）することなく、ホスト上で異なるUIDを使用できます。これによりボリューム管理が簡素化され、異なるユーザーマッピングを持つPod間でボリュームを共有するなどの機能が実現可能になります。ただし、ボリュームで使用されるファイルシステムはidmap mountsをサポートする必要があります。一般的なファイルシステムの多くはサポートされていますが、NFSは現在のサポートリストに含まれていません。

主要な詳細

• オプトインメカニズム: ユーザーはPod仕様の hostUsers: false を設定することでこの機能を有効にします。
• カーネル要件: シークレットやConfigMap用の tmpfs サポートのためには、Linuxカーネルバージョン6.3以上が推奨されます。overlayfsサポートの最低要件はカーネル5.19です。
• ランタイム互換性: Containerd バージョン2.0以上が必要です。CRI-Oはそのまま動作します。cri-dockerdを含むその他のランタイムは、現在Kubernetesとの組み合わせでこの機能をサポートしていません。
• セキュリティ上の利点: コンテナ間の横方向の移動（ラテラルムーブメント）を防ぎ、名前空間内で付与されたケーパビリティがホスト上では無効であることを保証します。
• 制限事項: カーネルモジュールの読み込みなど、ホストの特権を直接必要とするアプリケーションはユーザー名前空間を使用できません。NFSボリュームはidmap mountsに対応していません。

なぜ重要なのか

ソフトウェアエンジニアやプラットフォームチームにとって、このアップデートは長年のセキュリティジレンマに対処します。それは、互換性のためにコンテナ内でアプリケーションをrootとして実行しつつ、ホスト側のリスクを最小限に抑えるという課題です。従来、非rootでの実行には大規模なアプリケーションのリファクタリングや、ファイルパーミッションを管理するための複雑なカスタムソリューションが必要でした。ユーザー名前空間により、チームはホストレベルの特権を付与せずに内部でアプリケーションをrootとして実行でき、アプリケーションロジックとインフラストラクチャのセキュリティ制約を効果的に切り離すことができます。

デフォルトでの有効化は、コンテナエスケープ脆弱性に対する防御も強化します。CVE-2024-21626やCVE-2022-0492などの一般的なCVEは、エスケープしたプロセスが非特権的なホストIDのみを保持するため、緩和されます。これにより、侵害されたコンテナが同じノード上の他のコンテナのファイルやプロセスにアクセスできる可能性（横方向の移動）による攻撃面が減少します。kubeletは各Podに対して一意なホストUIDを保証することで、以前は一貫して達成することが難しかった分離性を強制します。

実施できること

• ノードがLinuxカーネル6.3以降を実行しているか確認し、tmpfs ボリュームとの完全な互換性を確保してください。
• コンテナランタイムをcontainerd 2.0+にアップグレードするか、互換性のあるバージョンのCRI-Oを使用していることを確認してください。
• ステージング環境のPod仕様に hostUsers: false を追加して既存ワークロードをテストし、パーミッション関連の問題がないか特定してください。
• クラスタで使用されているボリュームタイプを見直し、サポートが追加されるまでユーザー名前空間を利用するPodではNFSの使用を避けてください。
• 古いカーネルを使用している場合は、mount_setattr のmanページを参照して、特定のファイルシステムでのidmap mountサポートを確認してください。
• カーネルモジュールローダーなど、ホストレベルの特権を必要とするアプリケーションを評価してください。これらのアプリケーションはユーザー名前空間が有効な場合、機能しません。