Kubernetes 1.37、rootlessモードがベータに昇格

Kubernetes v1.37が、KubeletInUserNamespaceというfeature gateをベータに昇格させました。これを有効にすると、ノードのコンポーネントをrootではなく一般ユーザーとして動かせます。NTTのAkihiro Suda氏が2026年9月4日にKubernetesブログで発表しました。v1.37.0のリリース自体は2026年8月26日でした。

狙いは被害の抑え込みです。誰かがコンテナから抜け出しても、到達するのはホストのrootではなく、権限のない一般アカウントになります。

実際に非rootで動くもの

Suda氏は、この機能が対象とするノードコンポーネントを4種類挙げています。

• kubelet
• CRIおよびOCIのコンテナランタイム
• CNIのネットワークプラグイン
• kube-proxy

これらはすべて「can run as a non-root user on the host, using a Linux user namespace」と同氏は書いています。「This technique is also known as rootless mode」とも述べています。

user namespaceはLinuxカーネルの機能です。プロセスは自分専用の世界の中では自分をrootだと認識しますが、ホストから見れば普通のユーザーのままです。権限はnamespaceの内側では本物で、外側には存在しません。

これがセキュリティ上の論拠のすべてです。Suda氏は動機をはっきり書いています。ノードのコンポーネントには「historically had container-breakout vulnerabilities that could compromise full root privileges on the host」という経緯がありました。記事では、その例が5件挙げられています。

• CVE-2022-0811
• CVE-2023-27561
• CVE-2024-10220
• CVE-2025-31133
• CVE-2026-53488

rootlessモードでは、これらのいずれかを突いた脱出も一般ユーザーのアカウントまでしか届きません。ホストのrootには届きません。

混同されやすい区別

Kubernetesにはuser namespaceに関する機能が2つあり、取り違えやすくなっています。

Suda氏自身が線を引いています。rootlessモードは「should not be confused with user namespaces for pods」と書いています。そのもう一方の機能は、hostUsers: falseとUserNamespacesSupport feature gateで有効にします。v1.36から一般提供されています。こちらは「puts pods in user namespaces but still runs the node components as root」ものです。

つまり一方はワークロードをnamespaceに入れます。もう一方は土台側の仕組みを入れます。同じ問題の別々の半分を解いており、記事によれば両方を組み合わせられます。

実験からベータまで7年

この機能はゆっくり進んできました。日付そのものが難しさを物語ります。

段階	時期
最初の実験	2018年
アルファ、KEP-2033として	v1.22、2021年
ベータ	v1.37、2026年

アルファからベータまで5年かかりました。kubeletをrootなしで動かすことは、コンテナランタイム、ネットワーク、cgroup管理に同時に触れます。そのそれぞれが自前の対応を育てる必要がありました。

KEPとはKubernetes Enhancement Proposalのことで、この種の変更が通らなければならない設計文書です。GNOMEがいま自分たちのために起草しているのと同じ形の手続きです。

これが開発者にとって意味すること

計画を立てる前に、誰がkubeletを動かしているかを確認してください。EKS、GKE、AKSのようなマネージドサービスを使っているなら、そのプロセスは自分の管理下になく、この機能を自分で有効にはできません。効いてくるのは、自前のノードを運用している人、テストクラスタを組む人、エッジ環境を作る人です。

試す前に、必要条件が書かれた告知を読んでください。rootlessモードは特定のカーネル挙動、コンテナランタイムのバージョン、cgroupの委譲に依存しており、その具体はSuda氏の記事にあります。いま使っているノードイメージが条件を満たすと決めつけないでください。

ベータはベータとして扱ってください。Kubernetesにおいては、APIの形はおおむね固まっている一方、運用面の細部はまだであり、feature gateの既定値はリリース間で変わり得ます。失っても構わない場所で動かしてください。

有効にしない場合でも、役に立つ結論は残ります。いまの自分のノードで、コンテナからの脱出が実際にどこまで届くのかを問い直すことです。多くのクラスタでの正直な答えはホストのrootであり、その答えは今後、当たり前ではなく選択になります。