こんにちは！インフラやクラウドのセキュリティの世界へようこそ。
最近はKubernetes（K8s）を使ってアプリケーションを動かすのがすっかり当たり前になりましたよね。「コンテナを使えば環境構築がラクになる！」と、日々の開発を楽しんでいる方も多いのではないでしょうか。
でも、ちょっと待ってください。便利で強力なKubernetesだからこそ、セキュリティの「鍵の管理」を間違えると、とんでもない大惨事を引き起こしてしまうんです。
今回は、新人のIT担当者や「セキュリティはちょっと苦手……」という開発者の方に向けて、Kubernetesのセキュリティで一番大切な「RBAC（Role-Based Access Control：役割ベースのアクセス制御）」と、絶対にやっちゃいけない「権限のばら撒き（過剰付与）」のお話を、身近な防犯にたとえて分かりやすく紐解いていきますね。
一歩ずつ、安心して学んでいきましょう！
—
1. 家の鍵にたとえて理解する「Kubernetesの権限」
まずは、私たちの身近にある「家やオフィスの鍵」を想像してみてください。
皆さんは自分の家を出るとき、玄関の鍵をちゃんと閉めますよね。では、その鍵をどう管理していますか？
- 「家族みんなが自分の部屋に入れる鍵」
- 「近所の人なら誰でも自由に出入りできる合鍵」
- 「家中のあらゆる金庫も、勝手口も、窓のロックも一瞬で開けられる『マスターキー』」
最後の「マスターキー」を、もしご近所さん全員に配ったり、そこら辺の机の上にポンと置いておいたりしたらどうでしょう？ 考えただけでもゾッとしますよね。「泥棒に入ってください」と言っているようなものです。
Kubernetesの世界でも、これとまったく同じことが起きるんです。
Kubernetesの中には、たくさんのコンテナ（ポッド）やデータベース、設定ファイルが詰まっています。誰が・どのリソースに対して・どんな操作（見る、作る、消すなど）をしていいのかを決める仕組みが、RBAC（ロールベースアクセス制御）です。
そして、このRBACの設定をサボって、全員に「マスターキー」を配ってしまうのが、今回お話しする「ClusterRoleの過剰付与リスク」なんですね。
—
2. 攻撃者はどうやって「マスターキー」を狙うのか？
「うちのKubernetesクラスターは社内専用だし、みんな信頼できるメンバーだから大丈夫だよ」……そんな油断が、実は一番危なかったりします。
攻撃者は、あなたの会社の「一番セキュリティが甘いところ」を狙ってやってきます。例えば、開発環境で動いている、ちょっと古いウェブアプリケーションの脆弱性（セキュリティの穴）を突いて、そこに侵入してきたとしましょう。
もし、そのアプリケーションが動いているコンテナに、無駄に強力な権限（ClusterRoleのマスターキー）が与えられていたらどうなるでしょうか？
1. 侵入成功: 攻撃者がウェブアプリのコンテナを踏み台にして、内部に入り込みます。
2. 権限の乱用: コンテナの中に置いてあった（あるいは環境変数から盗み出した）強力なK8sの認証トークンを使って、Kubernetesの司令塔（APIサーバー）に話しかけます。
3. クラスター乗っ取り: 「私はマスターキーを持っています。すべての名前空間の全リソースを操作させてください！」と命令します。
4. 完全制圧: 攻撃者はクラスター内の全データの窃盗、マイニング（仮想通貨の不正採掘）用のコンテナの大量デプロイ、さらには他のクラウドサービスへの攻撃の踏み台へと、やりたい放題暴れ回るわけです。
これが、「たった一つの小さなアプリの隙が、システム全体の崩壊につながる」という、クラウドインフラ特有の恐ろしいメカニズムです。
—
3. 絶対に避けるべき「3つのアンチパターン」
現場の泥臭いインシデントを見ていると、大体次のような「うっかり設定ミス」が原因で事故が起きています。ご自身の環境はどうなっているか、チェックリスト代わりに見てみてくださいね。
① ワイルドカード（*）の安易な使用
「めんどくさいから、とりあえず全部許可にしちゃえ！」と、リソースや動詞に *（すべて）を指定してしまうパターンです。家の鍵で言えば、「すべての部屋のドアノブを外し、鍵なしで出入り自由にする」ようなものです。
② Namespace（名前空間）のスコープを無視したClusterRoleの濫用
特定の開発チームやアプリには、自分たちの部屋（Namespace）だけの権限を渡すべきなのに、クラスター全体（ClusterRole）を見渡せる最強の権限を渡してしまうパターンです。自分の家だけでなく、隣の家も、マンションの管理人室も自由に出入りできる合鍵を渡しているのと同じです。
③ 特権昇格を招く bind や escalate 権限
これが一番見落としがちな盲点です。bind や escalate という特殊な権限を持っていると、「自分より強い権限を持つ新しいルールを勝手に作り出す」ことができてしまいます。
例えるなら、「一般の住人なのに、自分で『マンションの管理人権限』を発行して、さらに上の階のオーナー権限まで手に入裏技」を使える状態です。恐ろしいですよね。
—
4. 実践！最小権限の原則に則ったセキュアなマニフェスト設計
では、具体的にどう直していけばいいのでしょうか？
ここからは、実務の現場でそのまま参考にできる「安全なKubernetesマニフェスト（YAMLファイル）」の書き方を見ていきましょう。
今回は、特定の開発チームが、自分たちの部屋（development 名前空間）の中だけで、アプリ（DeploymentやPod）を安全に管理するための設定例をご紹介します。
良い設定のサンプルコード
以下の設定では、ClusterRole ではなく Role を使い、かつ操作できる対象（resources）やアクション（verbs）を必要最小限に絞り込んでいます。
# 1. 役割（Role）の定義：許可する操作を「必要最小限」に絞る
# 注意: クラスター全体ではなく、特定のNamespaceに紐づく「Role」を使います。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: development # 権限をこの名前空間内だけに限定する
name: app-developer-role
rules:
# ポッドやデプロイメントの閲覧・作成・更新だけを許可
- apiGroups: ["", "apps"]
resources: ["pods", "deployments", "services"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
# 危険な "delete"（削除）や、特権昇格につながる "bind" "escalate" は絶対に含めない！
---
# 2. 結びつけ（RoleBinding）：誰にその役割を渡すのかを指定する
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-write-to-developers
namespace: development # Roleと同じ名前空間を指定
subjects:
- kind: ServiceAccount
name: dev-service-account # 紐付けるアプリケーション用のサービスアカウント名
namespace: development
roleRef:
kind: Role # ここで「ClusterRole」ではなく「Role」を指定するのがポイント
name: app-developer-role
apiGroup: rbac.authorization.k8s.io/v1この設定の嬉しいポイント
- 影響範囲の最小化: この設定が適用されたアカウントが万が一乗っ取られても、被害は
development名前空間の中だけで食い止められます。他の本番環境（productionなど）には一切手出しできません。 - 危険な動詞の排除:
deleteや、特権昇格につながる権限（bind,escalate）を一切持たせていないため、勝手に自分を最強の権限にアップグレードすることができません。
—
5. まとめ：今日からできる一歩
いかがでしたでしょうか？
Kubernetesの権限管理（RBAC）は、最初は言葉や仕組みが難しく感じるかもしれませんが、要は「誰に、どの部屋の、どの鍵を渡すか」を細かく整理するだけのシンプルな防犯対策です。
現場で新しいアプリケーションやCI/CDツールをデプロイするときは、以下の呪文を思い出してくださいね。
1. 「とりあえず ClusterRole と * を使っていないか？」と自分に問いかける。
2. 権限は必ず Namespace ごとにスコープ（範囲）を狭める。
3. bind や escalate といった、権限を増やす危険なナイフを安易に渡さない。
セキュリティは一日にして成らずですが、日々の小さな「めんどくさいけど、ちゃんと最小限にしよう」という心がけが、あなたとあなたの組織のシステムをサイバー脅威から守る最大の盾になります。
一歩ずつ、セキュアで快適なインフラライフを作っていきましょう！それではまた次回の記事でお会いしましょう。
コメント