Kubernetesのノードをroot権限なしで動かす「Rootless」という発想は、特殊なHPC環境だけの話ではなくなりつつあります。2026年8月にリリースされたKubernetes 1.37では、kubeletをuser namespace内で実行するKubeletInUserNamespace機能がBetaに昇格しました。一方でK3sは、以前から独自のRootless Modeを持っています。K3s rootlessを検討しているなら、この2つの方式がどう違うのかを正しく理解しておく必要があります。
1. Kubernetes 1.37で何が変わったのか — KubeletInUserNamespaceがBetaに
Kubernetesの公式リリースページによれば、v1.37「Garhwal」は67件の拡張を含み、そのうち19件がセキュリティ関連の変更です。中でも注目は、kubeletをはじめとするノードコンポーネントを非rootユーザーとして動かすKubeletInUserNamespace機能のBeta昇格です。
この機能は2018年、Usernetesプロジェクトでの実証実験から始まりました。2021年のv1.22でAlphaとなってから実に5年、ようやくBetaというマイルストーンに到達したことになります。Kubernetes公式ブログは、この機能によってkubelet・CRI・OCIランタイム・CNIプラグイン・kube-proxyといった主要なノードコンポーネントすべてを、Linuxのuser namespaceを使って非root権限で動作させられるようになったと説明しています。
有効化にはいくつかの前提条件があります。Cgroup v2の有効化、systemdユーザーセッション、/etc/subuid・/etc/subgidへのユーザー登録などです。手動設定が煩雑なため、現状はkindやminikube、あるいはRootless Docker/Podman上での利用が主な実践パターンとして案内されています。
2. K3sは実はずっと前からRootlessだった — ただし仕組みが違う
K3s rootlessという選択肢は、実はKubernetes本体がこの機能をBeta化するよりずっと前から存在していました。K3s公式ドキュメントでは、Rootless Modeについて「ホスト上の本物のrootを、コンテナブレイクアウト攻撃から保護するために、非特権ユーザーとしてK3sサーバーを実行できる」と説明されています。
ただし仕組みはKubernetes 1.37の方式と大きく異なります。K3sのRootless Modeは、kubeletだけでなくcontainerdやネットワークスタックを含むサーバープロセス全体をuser namespace化します。RootlessKitとslirp4netnsを使ってホストとuser namespace間の通信を仲介する設計です。
制約も見逃せません。K3sのRootless Modeが対応するのは純粋なCgroup v2のみで、Cgroup v1やハイブリッド構成では起動に失敗します。さらに複数ノードクラスタには対応せず、単一ノード上の単一プロセスとしてのみ動作します。実験的機能という位置づけのまま長く据え置かれているのは、この制約の大きさが理由の一つでしょう。
3. 2つのRootless方式、何が本質的に違うのか
両者の違いを整理すると、以下の3点に集約されます。
対象範囲の違い
- K3s Rootless Mode: サーバー全体（containerd・ネットワーキング含む）をuser namespace化
- KubeletInUserNamespace: kubelet・CRI・CNI・kube-proxyなど個々のノードコンポーネントをuser namespace化
外部ツールへの依存
K3sはRootlessKit・slirp4netnsという外部ツールに依存した独自実装です。一方、KEP-2033の設計方針では、kubeletとkube-proxyに最小限の修正（sysctl・rlimitエラーを無視する処理）を加えるだけで実現しており、Kubernetes本体への組み込みが前提になっています。
セキュリティ上の効果は共通
方式は違っても、狙いは同じです。ThoughtWorks Technology Radarが指摘する通り、Rootless化の核心的な価値は「攻撃対象領域全体を縮小し、コンテナからの権限昇格というセキュリティ問題のクラスをまるごと回避できる」という点にあります。Sysdigの分析も、KubeletInUserNamespaceのデフォルト有効化が「コンテナエスケープ攻撃の影響を大幅に軽減する」とまとめています。
4. マルチテナント／エアギャップ環境でどちらを選ぶべきか
実務上の判断基準はシンプルです。本番ワークロードにcgroupによるリソース制限が必須なら、現時点でK3sのRootless Modeは選択肢になりません。Cgroup自体に対応していないためです。この場合は、Kubernetes本体のKubelet-in-userns方式（まだBetaのため検証環境向け）を見据えるか、通常のroot実行を継続する判断になります。
一方で、検証環境やエッジ側の軽量ワークロード、あるいは「ホストを共有する複数チームの検証クラスタ」のようにマルチテナント性とroot隔離を優先したい場面では、K3sのRootless Modeは実用的な選択肢になり得ます。InfoQの報道でも、v1.37は「安定性・セキュリティ・AI/MLワークロード最適化」を軸にしたリリースと位置づけられており、Rootless化はその中でもデータ主権やコンプライアンス要件が厳しい領域への布石と言えます。
K3sベースのマネージド基盤であるKuboは、こうしたノードレベルのセキュリティ強化の恩恵を受けやすい設計です。特にデータを外部に出せない要件がある環境では、Kubo On-PremiseのようにAir-Gapped構成でK3sクラスタを運用しながら、ノード単位の攻撃対象領域を継続的に縮小していくアプローチが現実的な選択肢になります。
まとめ
Kubernetes 1.37でKubeletInUserNamespaceがBetaになったことで、「rootless」は一部の実験的プロジェクトの話から、Kubernetes本体の標準機能に近づきました。ただしK3sがもともと持っていたRootless Modeとは設計思想も制約も異なるため、「K3sはもう古い方式になった」と単純化するのは早計です。むしろ、両者とも発展途上の技術として、要件に応じて使い分けるフェーズにあると捉えるべきでしょう。
EKS/AKSのような高コスト・複雑なマネージドK8sに悩まされることなく、本格的なKubernetesのセキュリティ機能を取り入れていきたいなら、K3sベースで身軽に動ける基盤を選ぶことが近道です。Kuboなら、こうした最新のセキュリティアップデートを追従しながら、料金プランに見えるコスト効率の良さも両立できます。ノードレベルのセキュリティ設計について相談したい場合は、お問い合わせから気軽に相談してみてください。