[{"data":1,"prerenderedAt":319},["ShallowReactive",2],{"blog-ja-k3s-rootless-kubelet-user-namespace-k8s-137":3,"blog-related-ja-k3s-rootless-kubelet-user-namespace-k8s-137":268,"blog-ja-k3s-rootless-kubelet-user-namespace-k8s-137-alt":257},{"id":4,"title":5,"author":6,"body":7,"date":251,"description":252,"extension":253,"image":254,"locale":255,"meta":256,"navigation":257,"path":258,"seo":259,"stem":260,"tags":261,"__hash__":267},"blog\u002Fblog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137.md","KubeletInUserNamespaceがBetaになった日、K3sのRootless Modeは「時代遅れ」になったのか","Kubo Team",{"type":8,"value":9,"toc":237},"minimark",[10,19,24,31,44,59,76,80,86,95,103,110,114,120,123,127,142,145,153,156,171,175,181,188,197,212,215,218],[11,12,13,14,18],"p",{},"Kubernetesのノードをroot権限なしで動かす「Rootless」という発想は、特殊なHPC環境だけの話ではなくなりつつあります。2026年8月にリリースされたKubernetes 1.37では、kubeletをuser namespace内で実行する",[15,16,17],"code",{},"KubeletInUserNamespace","機能がBetaに昇格しました。一方でK3sは、以前から独自のRootless Modeを持っています。K3s rootlessを検討しているなら、この2つの方式がどう違うのかを正しく理解しておく必要があります。",[20,21,23],"h2",{"id":22},"_1-kubernetes-137で何が変わったのか-kubeletinusernamespaceがbetaに","1. Kubernetes 1.37で何が変わったのか — KubeletInUserNamespaceがBetaに",[11,25,26],{},[27,28],"img",{"alt":29,"src":30},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Fsection01.webp",[11,32,33,40,41,43],{},[34,35,39],"a",{"href":36,"rel":37},"https:\u002F\u002Fkubernetes.io\u002Freleases\u002F1.37\u002F",[38],"nofollow","Kubernetesの公式リリースページ","によれば、v1.37「Garhwal」は67件の拡張を含み、そのうち19件がセキュリティ関連の変更です。中でも注目は、kubeletをはじめとするノードコンポーネントを非rootユーザーとして動かす",[15,42,17],{},"機能のBeta昇格です。",[11,45,46,47,52,53,58],{},"この機能は2018年、",[34,48,51],{"href":49,"rel":50},"https:\u002F\u002Fwww.k8s.dev\u002Fresources\u002Fkeps\u002F2033\u002F",[38],"Usernetesプロジェクトでの実証実験から始まりました","。2021年のv1.22でAlphaとなってから実に5年、ようやくBetaというマイルストーンに到達したことになります。",[34,54,57],{"href":55,"rel":56},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2026\u002F09\u002F04\u002Fkubernetes-v1-37-rootless-beta\u002F",[38],"Kubernetes公式ブログ","は、この機能によってkubelet・CRI・OCIランタイム・CNIプラグイン・kube-proxyといった主要なノードコンポーネントすべてを、Linuxのuser namespaceを使って非root権限で動作させられるようになったと説明しています。",[11,60,61,62,67,68,71,72,75],{},"有効化には",[34,63,66],{"href":64,"rel":65},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fadminister-cluster\u002Fkubelet-in-userns",[38],"いくつかの前提条件","があります。Cgroup v2の有効化、systemdユーザーセッション、",[15,69,70],{},"\u002Fetc\u002Fsubuid","・",[15,73,74],{},"\u002Fetc\u002Fsubgid","へのユーザー登録などです。手動設定が煩雑なため、現状はkindやminikube、あるいはRootless Docker\u002FPodman上での利用が主な実践パターンとして案内されています。",[20,77,79],{"id":78},"_2-k3sは実はずっと前からrootlessだった-ただし仕組みが違う","2. K3sは実はずっと前からRootlessだった — ただし仕組みが違う",[11,81,82],{},[27,83],{"alt":84,"src":85},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Fsection02.webp",[11,87,88,89,94],{},"K3s rootlessという選択肢は、実はKubernetes本体がこの機能をBeta化するよりずっと前から存在していました。",[34,90,93],{"href":91,"rel":92},"https:\u002F\u002Fdocs.k3s.io\u002Fadvanced",[38],"K3s公式ドキュメント","では、Rootless Modeについて「ホスト上の本物のrootを、コンテナブレイクアウト攻撃から保護するために、非特権ユーザーとしてK3sサーバーを実行できる」と説明されています。",[11,96,97,98,102],{},"ただし仕組みはKubernetes 1.37の方式と大きく異なります。K3sのRootless Modeは、kubeletだけでなくcontainerdやネットワークスタックを含む",[99,100,101],"strong",{},"サーバープロセス全体","をuser namespace化します。RootlessKitとslirp4netnsを使ってホストとuser namespace間の通信を仲介する設計です。",[11,104,105,106,109],{},"制約も見逃せません。K3sのRootless Modeが対応するのは",[99,107,108],{},"純粋なCgroup v2のみ","で、Cgroup v1やハイブリッド構成では起動に失敗します。さらに複数ノードクラスタには対応せず、単一ノード上の単一プロセスとしてのみ動作します。実験的機能という位置づけのまま長く据え置かれているのは、この制約の大きさが理由の一つでしょう。",[20,111,113],{"id":112},"_3-2つのrootless方式何が本質的に違うのか","3. 2つのRootless方式、何が本質的に違うのか",[11,115,116],{},[27,117],{"alt":118,"src":119},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Fsection03.webp",[11,121,122],{},"両者の違いを整理すると、以下の3点に集約されます。",[124,125,126],"h3",{"id":126},"対象範囲の違い",[128,129,130,137],"ul",{},[131,132,133,136],"li",{},[99,134,135],{},"K3s Rootless Mode",": サーバー全体（containerd・ネットワーキング含む）をuser namespace化",[131,138,139,141],{},[99,140,17],{},": kubelet・CRI・CNI・kube-proxyなど個々のノードコンポーネントをuser namespace化",[124,143,144],{"id":144},"外部ツールへの依存",[11,146,147,148,152],{},"K3sはRootlessKit・slirp4netnsという外部ツールに依存した独自実装です。一方、",[34,149,151],{"href":49,"rel":150},[38],"KEP-2033の設計方針","では、kubeletとkube-proxyに最小限の修正（sysctl・rlimitエラーを無視する処理）を加えるだけで実現しており、Kubernetes本体への組み込みが前提になっています。",[124,154,155],{"id":155},"セキュリティ上の効果は共通",[11,157,158,159,164,165,170],{},"方式は違っても、狙いは同じです。",[34,160,163],{"href":161,"rel":162},"https:\u002F\u002Fwww.thoughtworks.com\u002Fen-au\u002Fradar\u002Fplatforms\u002Frootless-containers",[38],"ThoughtWorks Technology Radar","が指摘する通り、Rootless化の核心的な価値は「攻撃対象領域全体を縮小し、コンテナからの権限昇格というセキュリティ問題のクラスをまるごと回避できる」という点にあります。",[34,166,169],{"href":167,"rel":168},"https:\u002F\u002Fwww.sysdig.com\u002Fblog\u002Fkubernetes-1-37-new-security-features",[38],"Sysdigの分析","も、KubeletInUserNamespaceのデフォルト有効化が「コンテナエスケープ攻撃の影響を大幅に軽減する」とまとめています。",[20,172,174],{"id":173},"_4-マルチテナントエアギャップ環境でどちらを選ぶべきか","4. マルチテナント／エアギャップ環境でどちらを選ぶべきか",[11,176,177],{},[27,178],{"alt":179,"src":180},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Fsection04.webp",[11,182,183,184,187],{},"実務上の判断基準はシンプルです。本番ワークロードに",[99,185,186],{},"cgroupによるリソース制限が必須","なら、現時点でK3sのRootless Modeは選択肢になりません。Cgroup自体に対応していないためです。この場合は、Kubernetes本体のKubelet-in-userns方式（まだBetaのため検証環境向け）を見据えるか、通常のroot実行を継続する判断になります。",[11,189,190,191,196],{},"一方で、検証環境やエッジ側の軽量ワークロード、あるいは「ホストを共有する複数チームの検証クラスタ」のようにマルチテナント性とroot隔離を優先したい場面では、K3sのRootless Modeは実用的な選択肢になり得ます。",[34,192,195],{"href":193,"rel":194},"https:\u002F\u002Finfoq.com\u002Fnews\u002F2026\u002F09\u002Fkubernetes-1-37",[38],"InfoQの報道","でも、v1.37は「安定性・セキュリティ・AI\u002FMLワークロード最適化」を軸にしたリリースと位置づけられており、Rootless化はその中でもデータ主権やコンプライアンス要件が厳しい領域への布石と言えます。",[11,198,199,200,205,206,211],{},"K3sベースのマネージド基盤である",[34,201,204],{"href":202,"rel":203},"https:\u002F\u002Fkubo.hexabase.io\u002F",[38],"Kubo","は、こうしたノードレベルのセキュリティ強化の恩恵を受けやすい設計です。特にデータを外部に出せない要件がある環境では、",[34,207,210],{"href":208,"rel":209},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[38],"Kubo On-Premise","のようにAir-Gapped構成でK3sクラスタを運用しながら、ノード単位の攻撃対象領域を継続的に縮小していくアプローチが現実的な選択肢になります。",[20,213,214],{"id":214},"まとめ",[11,216,217],{},"Kubernetes 1.37でKubeletInUserNamespaceがBetaになったことで、「rootless」は一部の実験的プロジェクトの話から、Kubernetes本体の標準機能に近づきました。ただしK3sがもともと持っていたRootless Modeとは設計思想も制約も異なるため、「K3sはもう古い方式になった」と単純化するのは早計です。むしろ、両者とも発展途上の技術として、要件に応じて使い分けるフェーズにあると捉えるべきでしょう。",[11,219,220,221,224,225,230,231,236],{},"EKS\u002FAKSのような高コスト・複雑なマネージドK8sに悩まされることなく、本格的なKubernetesのセキュリティ機能を取り入れていきたいなら、K3sベースで身軽に動ける基盤を選ぶことが近道です。",[34,222,204],{"href":202,"rel":223},[38],"なら、こうした最新のセキュリティアップデートを追従しながら、",[34,226,229],{"href":227,"rel":228},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[38],"料金プラン","に見えるコスト効率の良さも両立できます。ノードレベルのセキュリティ設計について相談したい場合は、",[34,232,235],{"href":233,"rel":234},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[38],"お問い合わせ","から気軽に相談してみてください。",{"title":238,"searchDepth":239,"depth":239,"links":240},"",2,[241,242,243,249,250],{"id":22,"depth":239,"text":23},{"id":78,"depth":239,"text":79},{"id":112,"depth":239,"text":113,"children":244},[245,247,248],{"id":126,"depth":246,"text":126},3,{"id":144,"depth":246,"text":144},{"id":155,"depth":246,"text":155},{"id":173,"depth":239,"text":174},{"id":214,"depth":239,"text":214},"2026-10-28","Kubernetes 1.37でKubeletInUserNamespace(Rootless Mode)がBetaに昇格した。K3sは以前から独自のRootless Modeを持つが仕組みは全く別物だ。2つの方式の違いと、環境に応じた選び方を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137",{"title":5,"description":252},"blog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137",[262,263,264,265,266],"k3s","kubernetes","rootless","security","kubelet","a4VnsGaN7cSArFDhsvTzZRr3hV2Out80f4VDZ39RtXc",[269,278,287,295,303,311],{"path":270,"title":271,"description":272,"date":273,"tags":274},"\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant","K3sもKubernetesも\"デフォルトのServiceAccount\"が同じ罠を持っている。マルチテナント環境でautomountを放置すると何が起きるか","K3s vs K8sを比較しても、defaultのServiceAccountが抱えるautomountの罠は変わらない。マルチテナント環境での権限昇格リスクと、実際のCVEを交えた4層の対策を解説する。","2026-10-23",[262,263,275,276,277,265],"rbac","serviceaccount","multi-tenancy",{"path":279,"title":280,"description":281,"date":282,"tags":283},"\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage","restrictedを有効にしたらServiceLBが死んだ。K3sのPod Security Admissionに潜む、汎用ガイドにない設定差分","K3sでPod Security Admissionのrestrictedプロファイルを有効化したら、標準Kubernetesのガイド通りに進めたのにServiceLBが機能停止した。原因と安全な導入手順をK3s公式ハードニングガイドの記述とともに解説する。","2026-10-16",[262,263,284,285,286,265],"pod-security-admission","pod-security-standards","servicelb",{"path":288,"title":289,"description":290,"date":291,"tags":292},"\u002Fblog\u002Fja\u002Fk3s-zero-trust-kubectl-management-access","社内VPNを信頼するのをやめる。K3s管理アクセスを『境界のない』設計に変える3つの手順","K3sクラスタへの管理アクセスを、社内VPN前提のまま設計していないか。kubectl・Rancherダッシュボードへのアクセスを『境界』ではなく『アイデンティティ』で守るK3sゼロトラスト設計の3つの手順と、導入時に陥りやすい落とし穴まで具体的に解説する。","2026-09-05",[262,263,293,265,294],"zero-trust","rancher",{"path":296,"title":297,"description":298,"date":299,"tags":300},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[262,263,301,302,265],"cert-manager","tls",{"path":304,"title":305,"description":306,"date":307,"tags":308},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[262,263,309,310,265],"kata-containers","ai-agent",{"path":312,"title":313,"description":314,"date":315,"tags":316},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[262,263,317,318,265],"ci-cd","gitops",1793798695673]