ClusterRole + RoleBindingが必要な場面とは？

2025年1月31日 07:43

KubernetesのRBAC（Role-Based Access Control）を考えるとき、よく使われるのは「ClusterRole + ClusterRoleBinding」や「Role + RoleBinding」の組み合わせです。

例えば、クラスタ全体で統一した権限を与えたいなら「ClusterRole + ClusterRoleBinding」、Namespaceごとに細かく権限を管理したいなら「Role + RoleBinding」が適しています。

でも、「ClusterRole + RoleBinding」って本当に必要なの？」 と思ったことはありませんか？これを使わなくても、「ClusterRole + ClusterRoleBinding」で一括適用したり、「Role + RoleBinding」でNamespaceごとに管理すればいいのでは？

実は、「ClusterRole + RoleBinding」は、統一されたルールを持ちながら、特定のNamespaceのみに適用したいときに役立ちます。では、どんな場面で使うのかをまとめていきます。

ClusterRole + RoleBindingが活躍するシチュエーション

特定のNamespace内で統一されたルールを適用したいとき

例えば、開発チームのエンジニアが、担当するNamespaceのログだけを閲覧できるようにしたい場合を考えてみます。

開発チームごとにRoleを作成し、それぞれRoleBindingを設定する方法もありますが、Namespaceが増えるたびに設定が必要になるので、管理が面倒になります。

そこで、ClusterRole（ログ閲覧のルール）をクラスタ全体に作成し、RoleBindingで特定のNamespaceにだけ適用する方法が便利です。

この方法を使うことで、すべての開発チームに統一したログ閲覧のルールを適用しつつ、アクセスできる範囲を制限できます。

📌 Kubernetesの設定（YAML）

ClusterRole（クラスタ全体のログ閲覧権限）

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: log-viewer
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

RoleBinding（開発チームのNamespace "dev-team" に適用）

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev-team
  name: log-viewer-binding
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: log-viewer
  apiGroup: rbac.authorization.k8s.io

この設定により、開発チームのエンジニアは「dev-team」Namespaceのログだけを閲覧できるようになります。

管理者が特定のNamespace内で統一された操作を行えるようにしたいとき

運用チームのメンバーには、どのNamespaceでもPodを削除できる権限を持たせたい場合を考えてみましょう。

「ClusterRole + ClusterRoleBinding」を使うと、クラスタ全体でPodの削除が可能になり、すべてのNamespaceのリソースにアクセスできるようになってしまいます。しかし、運用チームが担当するNamespaceだけでこの権限を持たせたい場合には、**「ClusterRole + RoleBinding」**の組み合わせが適しています。

この方法を使えば、Namespaceごとに異なるユーザーに適用できるため、不要なアクセス権を与えずに済みます。

📌 Kubernetesの設定（YAML）

ClusterRole（Pod削除権限）

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-deleter
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["delete"]

RoleBinding（運用チームの"staging" Namespaceに適用）

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: staging
  name: pod-deleter-binding
subjects:
- kind: Group
  name: ops-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-deleter
  apiGroup: rbac.authorization.k8s.io

この設定を適用すると、運用チームのメンバーは "staging" Namespace 内でのみPodの削除が可能になります。

「ClusterRole + ClusterRoleBinding」との違いは？

ここで、「ClusterRole + ClusterRoleBindingを使えば、わざわざRoleBindingしなくてもいいのでは？」と考えるかもしれません。

「ClusterRole + ClusterRoleBinding」は、すべてのNamespaceで一律に適用されるのに対し、「ClusterRole + RoleBinding」は、適用するNamespaceを選択できるという違いがあります。

例えば、ログ閲覧の権限をクラスタ全体のすべてのNamespaceに適用するなら「ClusterRole + ClusterRoleBinding」でOKです。

しかし、特定のNamespaceのみに制限したい場合は、「ClusterRole + RoleBinding」を使うことで、必要な範囲だけに適用できるようになります。

ClusterRole + RoleBindingを使うべきケース

この組み合わせが役立つのは、次のような状況です。

(1) 同じ権限を統一して適用したいが、すべてのNamespaceではなく、一部のNamespaceに限定したいとき
→ 例えば、開発チームにログ閲覧権限を付与するが、それぞれの担当するNamespaceにだけ適用したい場合。

(2) Namespaceごとに異なるユーザーやグループに適用したいとき
→ 運用チームのメンバーにPod削除権限を与えるが、運用するNamespaceだけで権限を持たせたい場合。

まとめ

KubernetesのRBACを設計するときは、「どの範囲で適用するか？」 を考えることが大切です。

「ClusterRole + ClusterRoleBinding」を使えばクラスタ全体で統一した権限を適用できますが、すべてのNamespaceに適用されてしまうため、「Namespaceごとに適用する範囲を分けたい」 という場合には「ClusterRole + RoleBinding」の方が適しています。

「ルールは統一したいけど、適用する範囲は制限したい」ときに、この組み合わせを活用すると、より適切なRBAC管理ができますよ！