RBAC ― 誰が何をできるかを制御｜Kubernetes学習コース BecomeCoder

導入

チームでクラスタを運用すると、「新人は本番の Pod を削除できないようにしたい」「この監視ツールには読み取りだけ許したい」といった権限の線引きが必要になります。これを担うのが RBAC（Role-Based Access Control、役割ベースのアクセス制御） です。

説明

RBAC は3つの登場人物の組み合わせで表現します。

主体（誰が） … 人間のユーザーや、Pod に紐づく ServiceAccount（サービスアカウント、アプリの身分証）。
Role / ClusterRole（何をしてよいか） … 「Pod を読める」「Secret を作れる」といった権限の束。Role は1つの Namespace 内だけ、ClusterRole はクラスタ全体に効きます。
RoleBinding / ClusterRoleBinding（結び付け） … 「この主体に、この権限の束を与える」という紐づけ。

graph LR
    SA["主体<br/>ServiceAccount / ユーザー"] --> RB["RoleBinding<br/>（結び付け）"]
    RB --> ROLE["Role<br/>（Podを読める等の権限）"]

権限の束（Role）の例です。この Role は「Pod を見ることだけ」を許します。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]   # 読み取り系のみ（作成・削除は不可）

そしてこの Role を、特定の主体に結び付けます。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: ServiceAccount
    name: monitoring-sa
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RBAC の設計で大切なのは 最小権限の原則（least privilege） ――「その人・そのアプリが仕事に必要な分だけ」を与え、それ以上は許さない考え方です。監視ツールには読み取りだけ、デプロイ担当には自分の Namespace だけ、というように絞ることで、事故や乗っ取りの被害を最小化できます。

前章の Secret を思い出してください。「base64 は暗号化ではない」ので、Secret を守る要はこの RBAC で読める人を絞ることでした。RBAC は k8s のセキュリティの土台です。