「鍵を渡しすぎていませんか？」KubernetesのRBACで守る、クラウド時代のセキュリティの基本
こんにちは！日々、システムの「守り」と格闘しているエンジニアの皆さん、お疲れ様です。
今日は、Kubernetes（K8s）という大きなシステムの「鍵の管理」、つまりRBAC（ロールベースアクセス制御）についてお話しします。
「Kubernetesって便利だけど、設定が難しそう…」そんなふうに感じていませんか？でも大丈夫。実はRBACの考え方は、皆さんが普段住んでいる「家の防犯」と全く同じなんです。一歩ずつ、丁寧に紐解いていきましょう。
—
1. なぜ「鍵の渡しすぎ」がいけないの？
想像してみてください。あなたは一軒家の持ち主です。友人や業者に家へ入ってもらいたいとき、どうしますか？
- ダメな例： 「合鍵」を渡して、家中どこでも自由に開け閉めできるようにする。
- 良い例： 「キッチンにだけ入れる鍵」や「玄関までしか入れない鍵」を渡す。
Kubernetesでいう「鍵」がRBACです。
もし、たった一つのPod（家の中の小部屋のようなもの）が、クラスタ全体の「マスターキー（権限）」を持っていたらどうなるでしょう？
もしそのPodが外部からの攻撃で乗っ取られたら、犯人はその鍵を使ってクラスタ全体を破壊したり、情報を盗み出したりできてしまいます。これが「権限昇格」という、セキュリティ事故の入り口です。
—
2. RBACの登場人物を整理しよう
RBACは大きく分けて「誰が（Subject）」「何をできるか（Role）」「どう結びつけるか（Binding）」の3要素で決まります。
① Role（何ができるか）
「何ができるか」を定義したリストです。
例：「Podを読み取ることはできるけど、消すことはできない」というルールを書きます。
② RoleBinding（誰に渡すか）
作った「Role」を、特定の「ServiceAccount（プログラム用のID）」に紐付けます。
—
3. 実践！最小権限の原則で設定してみよう
それでは、具体的に「読み取り専用の鍵」を渡す設定を書いてみましょう。
1. Roleの定義：できることを制限する
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader-role # 名前は分かりやすく
rules:
- apiGroups: [“”]
resources: [“pods”] # Podに対してのみ
verbs: [“get”, “list”] # 見るだけ（削除や更新はできない）
—
2. RoleBinding：誰に鍵を渡すか決める
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
subjects:
- kind: ServiceAccount
name: my-app-service-account # 対象のアプリケーション用ID
namespace: default
roleRef:
kind: Role
name: pod-reader-role # 上で作ったルールを適用
apiGroup: rbac.authorization.k8s.io
この設定なら、もしアプリケーションが乗っ取られても、犯人は他のPodを勝手に操作することはできません。「できることを絞る」ことが、最大の防衛策なんです。
—
4. 攻撃者が狙う「盲点」：ClusterRoleにご注意！
ここで一つ、注意点があります。ClusterRoleという強力な鍵の存在です。
先ほどの「Role」は特定の名前空間（家の中の部屋）限定でしたが、「ClusterRole」は家全体、つまりクラスタ全体に影響を与えます。もし間違って、適当なPodに「ClusterRole」を与えてしまうと、全室の鍵を渡したのと同じことになります。
チェックポイント：
- 名前空間をまたぐ必要があるか？
- 本当にその権限が必要か？
迷ったら、まずは限定的な「Role」から始めてください。必要になったら広げるのが、セキュリティの鉄則です。
—
5. 監査（オーディット）で「誰が何をしたか」を確認しよう
最後に、どんなに気をつけていても「誰かが鍵を間違って使っていないか」をチェックするのは重要です。KubernetesのAudit Log（監査ログ）は、防犯カメラのような役割を果たします。
ログを確認することで、以下のような不審な動きを見つけることができます。
- 「いつもは見ないはずの権限設定をいじろうとしているPodがいる」
- 「許可されていないのに、他の名前空間を覗こうとしている」
kubectl get events を眺めたり、クラウドプロバイダーが提供するログ機能を確認する癖をつけてみてください。「いつもと違う動き」に気づくこと、それがプロのセキュリティエンジニアへの第一歩です。
—
まとめ：セキュリティは「面倒」ではなく「安心」を作る作業
セキュリティの設定は、最初は少し面倒に感じるかもしれません。でも、これは「自分の大切なシステム」を泥棒から守るための、とても頼もしい防壁です。
1. 最小権限の原則： 必要以上の鍵は渡さない。
2. RoleBindingを細かく分ける： 役割に応じて鍵を使い分ける。
3. 定期的に見直す： 引っ越しをした後に鍵を交換するように、定期的に権限を確認する。
今日から皆さんのクラスタでも、まずは「誰にどんな鍵を渡しているか」を確認することから始めてみませんか？
もし分からないことがあれば、いつでもまた聞きに来てくださいね。一緒に安全なシステムを作り上げていきましょう！
コメント