mhKubernetesでは、クラスタのリソースに対するアクセス制御を行う仕組みとして RBAC（Role-Based Access Control） が用意されています。
これは文字通り「ロールに基づいたアクセス制御」で、「誰が」「何を」「どこで」できるのか を明確に設定できます。
✅ なぜRBACが必要なの？
Kubernetesクラスターでは、多くのリソース（Pod、Service、Secretなど）と、多くのユーザー（開発者、CI/CDツール、管理者など）が存在します。
そのため、全員にフルアクセスを許してしまうと事故やセキュリティリスクが増大します。
RBACを使うことで：
- 特定のユーザーに「Podの参照だけ許可」などの制限ができる
- チームごとにアクセス範囲を分離できる
- 最小権限の原則（必要な権限だけ与える）を実現できる
🧩 RBACの基本構成
RBACでは主に以下の4つのリソースが登場します：
| リソース | 役割 |
|---|---|
| Role / ClusterRole | どんな操作を許可するか（例: Podの取得） |
| RoleBinding / ClusterRoleBinding | 誰にそのロールを割り当てるか |
簡単に言うと：
- Role は Namespace単位 の権限
- ClusterRole は クラスタ全体 にまたがる権限
- RoleBinding / ClusterRoleBinding で ユーザー（またはServiceAccount）にロールを紐づけます
🧪 例：特定Namespace内でPodの一覧取得だけ許可する
# Roleの定義
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev-team
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]# RoleBindingの定義
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: dev-team
subjects:
- kind: User
name: "alice"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioこの例では：
aliceというユーザーはdev-team名前空間の Pod に対してget/listができます- 他のリソース（Secretなど）や他のNamespaceにはアクセスできません
🛡 ロール設計のポイント
- 最小権限の原則を意識する
→ 必要最小限のverbs・resourcesを許可 - Namespaceごとの分離
→ チームごとに Role/RoleBinding を分けると管理しやすい - ClusterRole は慎重に
→ClusterRoleは強力なので、基本的には管理者やCI/CDに限定する - ServiceAccount にバインドすることで、アプリに権限を与える
→ 人だけでなく、アプリ（Pod）にも認証・認可が必要な場面で使う
💡 よくあるユースケース
| ユースケース | 使用するリソース |
|---|---|
| チームごとに Namespace 内リソースを操作可能にする | Role + RoleBinding |
| CI/CDツールにクラスタ全体のデプロイ権限を与える | ClusterRole + ClusterRoleBinding |
| Pod に読み取り専用のSecretアクセスを許可 | Role + RoleBinding を ServiceAccount に紐付け |
📌 RBAC設定の確認方法
# あるユーザーが Pod の get 権限を持っているか確認
kubectl auth can-i get pods --as alice --namespace dev-team🔚 まとめ
RBACはKubernetesにおけるアクセス制御の中核であり、安全な運用には欠かせません。
- ロール（Role / ClusterRole）で「何ができるか」を定義し、
- バインディング（RoleBinding / ClusterRoleBinding）で「誰が使うか」を紐づけます。
