[{"data":1,"prerenderedAt":363},["ShallowReactive",2],{"blog-ja-k3s-k8s-default-serviceaccount-automount-rbac-multi-tenant":3,"blog-related-ja-k3s-k8s-default-serviceaccount-automount-rbac-multi-tenant":314,"blog-ja-k3s-k8s-default-serviceaccount-automount-rbac-multi-tenant-alt":302},{"id":4,"title":5,"author":6,"body":7,"date":296,"description":297,"extension":298,"image":299,"locale":300,"meta":301,"navigation":302,"path":303,"seo":304,"stem":305,"tags":306,"__hash__":313},"blog\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant.md","K3sもKubernetesも\"デフォルトのServiceAccount\"が同じ罠を持っている。マルチテナント環境でautomountを放置すると何が起きるか","Kubo Team",{"type":8,"value":9,"toc":286},"minimark",[10,18,26,31,45,62,66,72,75,91,111,124,128,134,141,160,167,171,177,186,189,193,199,202,236,251,264,267,270],[11,12,13],"p",{},[14,15],"img",{"alt":16,"src":17},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection01.webp",[11,19,20,21,25],{},"ある検証用のマルチテナントクラスタで、テナントAのPodからテナントBのSecretsが読めてしまうという事故が起きた。原因を追うと、どちらのテナントのNamespaceにも「k3s vs k8s」の比較記事でよく語られるような特別な設定ミスはなかった。あったのは、Namespace作成時に自動生成される",[22,23,24],"code",{},"default","ServiceAccountのトークンが、何も考えずにPodへ自動マウントされ続けていたという、ただそれだけの状態だった。",[27,28,30],"h2",{"id":29},"_1-検証クラスタで起きた隣のテナントのsecretが読めたという事故","1. 検証クラスタで起きた「隣のテナントのSecretが読めた」という事故",[11,32,33,34,37,38,41,42,44],{},"経緯はこうだ。複数チームが同じK3sクラスタを共有する検証環境で、チームごとにNamespaceを分けて「隔離できている」とみなしていた。しかしRoleBindingの一部が",[22,35,36],{},"ClusterRole","に紐づく",[22,39,40],{},"ClusterRoleBinding","として広めに設定されており、あるPodの",[22,43,24],{},"ServiceAccountトークンを使ってAPIサーバーに問い合わせると、本来アクセスできないはずの別Namespaceのリソースが列挙できてしまった。",[11,46,47,48,55,56,61],{},"攻撃者がまず侵入後に探すのは、まさにこの種の「使われていないのに存在する」認証情報だ。多くのPodには実際にはKubernetes APIを呼ぶ処理など存在しないにもかかわらず、トークンだけは律儀にマウントされている。この種の横展開（lateral movement）のパターンは、MITRE ATT&CKの観点からも繰り返し指摘されている（",[49,50,54],"a",{"href":51,"rel":52},"https:\u002F\u002Fwww.redhat.com\u002Fen\u002Fblog\u002Fprotecting-kubernetes-against-mitre-attck-lateral-movement",[53],"nofollow","Red Hatの解説記事","）。マネージドなK8s基盤であれば、こうした放置資産の存在そのものに運用者が気づきやすい設計にしやすい。",[49,57,60],{"href":58,"rel":59},"https:\u002F\u002Fkubo.hexabase.io\u002F",[53],"Kubo","のようにクラスタの構成をCaptain UIの可視化された管理画面で把握できる環境は、この種の「気づかれない穴」を減らす選択肢になる。",[27,63,65],{"id":64},"_2-k3s-vs-k8sで比較してもdefaultのserviceaccountは同じ罠を持っている","2. k3s vs k8sで比較しても、\"defaultのServiceAccount\"は同じ罠を持っている",[11,67,68],{},[14,69],{"alt":70,"src":71},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection02.webp",[11,73,74],{},"ここが見落とされやすい点だ。「k3s vs k8s」という比較軸で語られるのは、たいていCNIの選択肢やコントロールプレーンの構成、CI\u002FCDとの相性といった運用面の違いであり、RBACの仕組みそのものには差がない。Role・ClusterRole・RoleBinding・ClusterRoleBindingという4つのオブジェクトはk3sでもバニラのKubernetesでも完全に同一だ。",[11,76,77,78,80,81,84,85,90],{},"ではk3sとk8sで何が違うのか。Kubernetesは各Namespaceに",[22,79,24],{},"という名前のServiceAccountを自動生成し、Podの仕様で明示的に指定しない限り、このServiceAccountのAPI認証トークンが",[22,82,83],{},"\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Ftoken","に自動マウントされる。これは",[49,86,89],{"href":87,"rel":88},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fconfigure-pod-container\u002Fconfigure-service-account\u002F",[53],"Kubernetes公式ドキュメント","に明記されている既定動作であり、k3sでも素のKubernetesでも変わらない。",[11,92,93,94,97,98,110],{},"さらに厄介なのが優先順位の罠だ。ServiceAccount側で",[22,95,96],{},"automountServiceAccountToken: false","を設定していても、",[99,100,101,102,105,106,109],"strong",{},"Pod の",[22,103,104],{},".spec","で",[22,107,108],{},"true","を指定すると、そちらが優先される","。「ServiceAccountで塞いだはずなのに、特定のPodだけ穴が開いていた」という事故は、この優先順位を知らないと再現性高く起こる。",[11,112,113,114,117,118,123],{},"一方でk3sには独自の事情もある。k3sは",[22,115,116],{},"\u002Fetc\u002Francher\u002Fk3s\u002Fk3s.yaml","に強力な管理者kubeconfigを同梱した状態でブートストラップされる。検証・ホームラボ用途ではこれが便利に働くが、同じ感覚のままマルチテナントの本番運用へ持ち上げると、RBACを意識せず管理者権限で触り始めた経験がそのまま\"緩いRoleBinding\"として残ってしまう。実際、",[49,119,122],{"href":120,"rel":121},"https:\u002F\u002Fdocs.k3s.io\u002Fsecurity\u002Fhardening-guide",[53],"k3s公式のCIS Hardening Guide","でも、NetworkPolicyやPod Security Standardsはデフォルトでは適用されず、各Namespaceへの明示的な設定が必須だと明記されている。「k3sは軽量だから後回しでいい」という思い込みが、ここでも同じ落とし穴につながる。",[27,125,127],{"id":126},"_3-他人事ではないcve-2026-61549が示すserviceaccountnameの外部指定の危険","3. 他人事ではない。CVE-2026-61549が示す\"serviceAccountNameの外部指定\"の危険",[11,129,130],{},[14,131],{"alt":132,"src":133},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection03.webp",[11,135,136,137,140],{},"「ServiceAccountの指定を外部入力に任せると何が起きるか」を示す実例が、2026年に公表されたCI\u002FCDツールWoodpeckerのKubernetesバックエンドの脆弱性だ。パイプラインYAMLの",[22,138,139],{},"backend_options.kubernetes.serviceAccountName","フィールドが、検証なしにそのままPod仕様へ渡されていた。",[11,142,143,144,149,150,155,156,159],{},"その結果、該当リポジトリへのpushアクセス権さえあれば、誰でもパイプラインNamespace内の任意のServiceAccountを指定できてしまった。もし特権的なServiceAccountがそのNamespaceに存在すれば、攻撃者のパイプラインPodがそのトークンを取得し、Secretsの読み取り・クラスタリソースの列挙・cluster-admin権限への昇格まで到達しうる。",[49,145,148],{"href":146,"rel":147},"https:\u002F\u002Fgithub.com\u002Fadvisories\u002FGHSA-qf34-295c-26v8",[53],"GitHub Security Advisory（GHSA-qf34-295c-26v8）","はCVSSスコア8.2（High）と評価しており、",[49,151,154],{"href":152,"rel":153},"https:\u002F\u002Fsecurelayer7.net\u002Flab\u002Fcve-2026-61549-woodpecker-ci-kubernetes-serviceaccountname-privilege-escalation",[53],"詳細な技術解説","によれば影響範囲はv3.16.0未満の全バージョンに及ぶ。修正版では",[22,157,158],{},"ServiceAccountNameAllowFromStep","というゲート機能が追加され、デフォルトでは無効化・明示的な環境変数設定がない限り機能しないようになった。",[11,161,162,163,166],{},"CI\u002FCDパイプラインに限らず、「ServiceAccount名をどこかの入力値から決める」設計は、defaultのServiceAccountの罠と同じ根を持つ。GitOpsパイプラインを",[49,164,60],{"href":58,"rel":165},[53],"のようにArgoCD\u002FFluxとの標準統合で運用する場合も、ServiceAccountの割り当てルールをテンプレート側で固定し、パイプライン定義から自由に指定させない設計にしておく価値がここにある。",[27,168,170],{"id":169},"_4-この手口は実際に増えている脅威統計が示す現実","4. この手口は実際に増えている（脅威統計が示す現実)",[11,172,173],{},[14,174],{"alt":175,"src":176},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection04.webp",[11,178,179,180,185],{},"「一部の特殊な構成でしか起きない」と思われがちだが、実際のデータは逆を示している。",[49,181,184],{"href":182,"rel":183},"https:\u002F\u002Funit42.paloaltonetworks.com\u002Fmodern-kubernetes-threats\u002F",[53],"Palo Alto Networks Unit42の脅威レポート","によれば、Kubernetesのトークン窃取を含む脅威アクターの活動は前年比で282%増加し、クラウド環境の22%でServiceAccountトークン窃取を疑う活動が検出されている。Kubernetes関連のアラート件数も、2024年の約12万件から2025年には約47万件へと3.8倍近くに急増したと報告されている。",[11,187,188],{},"これらの数値が示すのは、「defaultのServiceAccountを放置する」という構成ミスが、攻撃者にとって珍しくない標的になっているという現実だ。マルチテナント環境ではなおさら、1つのNamespaceの甘さが他のテナントにまで波及しうる。",[27,190,192],{"id":191},"_5-マルチテナント環境を守る4層の対策","5. マルチテナント環境を守る4層の対策",[11,194,195],{},[14,196],{"alt":197,"src":198},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection05.webp",[11,200,201],{},"RBAC単体での対策は不十分だ。マルチテナント環境を現実的に守るには、少なくとも次の4層を組み合わせる必要がある。",[203,204,205,212,218,224],"ul",{},[206,207,208,211],"li",{},[99,209,210],{},"automountServiceAccountTokenの明示的な無効化",": ServiceAccountとPod両方で設定し、Pod側が優先される仕様を踏まえて漏れがないか確認する",[206,213,214,217],{},[99,215,216],{},"NetworkPolicyのデフォルト全拒否",": 「まず全通信を遮断し、必要な経路だけ明示的に許可する」というアプローチがテナント間通信の遮断に有効",[206,219,220,223],{},[99,221,222],{},"ResourceQuota \u002F LimitRangeによるリソース分離",": テナントごとにCPU・メモリの合計requestと上限limitを明示し、一方のテナントが他方の性能を圧迫しないようにする",[206,225,226,229,230,232,233,235],{},[99,227,228],{},"ポリシーエンジンによる自動強制",": Kyvernoのようなポリシーエンジンを使えば、新規Namespace作成時に生成される",[22,231,24],{},"ServiceAccountへ",[22,234,96],{},"を自動パッチでき、設定漏れを構造的に防げる",[11,237,238,239,244,245,250],{},"これらの組み合わせは、",[49,240,243],{"href":241,"rel":242},"https:\u002F\u002Fvcluster.com\u002Fblog\u002Fbest-practices-for-achieving-isolation-in-kubernetes-multi-tenant-environments",[53],"マルチテナント分離のベストプラクティスを解説する記事","でも、RBAC・NetworkPolicy・ResourceQuotaの3点セットが「実用的な分離」の最低条件として挙げられている。",[49,246,249],{"href":247,"rel":248},"https:\u002F\u002Fkyverno.io\u002Fpolicies\u002Fother\u002Fdisable-automountserviceaccounttoken\u002Fdisable-automountserviceaccounttoken\u002F",[53],"Kyvernoの自動ミューテートポリシー","のようにクラスタ全体へ一貫して適用できる仕組みを使えば、Pod単位の設定漏れというヒューマンエラーをなくせる。",[11,252,253,257,258,263],{},[49,254,256],{"href":58,"rel":255},[53],"Kubo Cloud","のようなマネージド環境では、Captain UIという可視化された管理画面でクラスタの状態をブラックボックスにせず把握できるため、こうした「設定したつもり」のギャップに気づきやすくなる。金融・医療のようにデータ主権要件が厳しい業種では、",[49,259,262],{"href":260,"rel":261},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[53],"Kubo On-Premise","のように自社管理のまま同等のマルチテナント設計を適用できる選択肢も有効だ。",[27,265,266],{"id":266},"まとめ",[11,268,269],{},"k3sとKubernetesを比較するとき、議論はCNIやコントロールプレーンの構成に偏りがちだが、RBACとServiceAccountの既定動作に関しては両者に差がない。defaultのServiceAccountをそのまま使い続けることが、検証環境から本番のマルチテナント運用へ移行した瞬間にリスクへ変わる。CVE-2026-61549のような実例や、前年比282%という脅威統計が示すように、これは理論上の懸念ではなく現実に増えている攻撃面だ。",[11,271,272,273,276,277,279,280,285],{},"automountの無効化・NetworkPolicy・ResourceQuota・ポリシーエンジンによる自動強制という4層を、Podを作るたびに人力で確認するのではなく、基盤側にテンプレート化しておくこと。",[49,274,60],{"href":58,"rel":275},[53],"はK3sベースの本格的なKubernetesでありながら、そうしたマルチテナント設計を最初から組み込める環境として、この種の\"気づかれない穴\"を減らす選択肢になる。まずは自分のクラスタの",[22,278,24],{},"ServiceAccountが今どうなっているか、確認するところから始めてみてほしい。",[49,281,284],{"href":282,"rel":283},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[53],"お問い合わせ","から相談することもできる。",{"title":287,"searchDepth":288,"depth":288,"links":289},"",2,[290,291,292,293,294,295],{"id":29,"depth":288,"text":30},{"id":64,"depth":288,"text":65},{"id":126,"depth":288,"text":127},{"id":169,"depth":288,"text":170},{"id":191,"depth":288,"text":192},{"id":266,"depth":288,"text":266},"2026-10-23","K3s vs K8sを比較しても、defaultのServiceAccountが抱えるautomountの罠は変わらない。マルチテナント環境での権限昇格リスクと、実際のCVEを交えた4層の対策を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant",{"title":5,"description":297},"blog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant",[307,308,309,310,311,312],"k3s","kubernetes","rbac","serviceaccount","multi-tenancy","security","wF-zrm0h0_BDyrK5GTXPtJAPE1IwoI9bww6rrxPiCfA",[315,323,332,340,348,356],{"path":316,"title":317,"description":318,"date":319,"tags":320},"\u002Fblog\u002Fja\u002Fkubernetes-secrets-rbac-etcd-encryption","Base64を見て安心するな。KubernetesのSecretsが「素通し」される理由とRBAC設計の落とし穴","KubernetesのSecretsはBase64エンコードされているだけで、暗号化されていない。etcdへの平文相当保存とRBACの過剰権限が引き起こす事故と、K3s本番運用で実践すべきSecrets管理の対策を解説する。","2026-07-29",[308,307,321,309,312,322],"secrets-management","etcd-encryption",{"path":324,"title":325,"description":326,"date":327,"tags":328},"\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",[307,308,329,330,331,312],"pod-security-admission","pod-security-standards","servicelb",{"path":333,"title":334,"description":335,"date":336,"tags":337},"\u002Fblog\u002Fja\u002Fk3s-zero-trust-kubectl-management-access","社内VPNを信頼するのをやめる。K3s管理アクセスを『境界のない』設計に変える3つの手順","K3sクラスタへの管理アクセスを、社内VPN前提のまま設計していないか。kubectl・Rancherダッシュボードへのアクセスを『境界』ではなく『アイデンティティ』で守るK3sゼロトラスト設計の3つの手順と、導入時に陥りやすい落とし穴まで具体的に解説する。","2026-09-05",[307,308,338,312,339],"zero-trust","rancher",{"path":341,"title":342,"description":343,"date":344,"tags":345},"\u002Fblog\u002Fja\u002Fk3s-mcp-ai-agent-rbac-permission-bypass","AIエージェントに『Pod見てきて』と頼んだら、K3sクラスタごと乗っ取れた。MCPサーバーの権限バイパスが教えるRBAC設計の盲点","MCP経由でAIエージェントにKubernetes操作を任せる際の権限バイパスの実例から、K3s\u002FKubernetesクラスタに必須のRBAC設計と監査ログ分離の実践を解説する。","2026-09-03",[307,308,346,309,347],"mcp","ai-agent",{"path":349,"title":350,"description":351,"date":352,"tags":353},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[307,308,354,355,312],"cert-manager","tls",{"path":357,"title":358,"description":359,"date":360,"tags":361},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[307,308,362,347,312],"kata-containers",1792736039421]