KubernetesのRBACの組み合わせに関して

KubernetesのRBACって、わかりづらいですよね。
ClusterRoleとRoleに関して今回も例え話で捉えていきましょう。

4つのRBACの組み合わせを会社内の「ファイルアクセス権限」の例にしてみます。

---

シナリオ

会社には、プロジェクトに関する資料を保管する「フォルダ」が複数あり、特定の部門や社員にのみ閲覧権限を与える必要があります。このフォルダの権限には、「部門専用のフォルダ」や「会社全体で共通のフォルダ」などがあり、それぞれ異なる組み合わせでアクセス権限が割り当てられています。

4つのRBACの組み合わせ（3つの有効な組み合わせと1つの無効な組み合わせ）

1. Role + RoleBinding（部門内でのみ使えるフォルダと権限の組み合わせ）

• Role（部門専用のフォルダの権限）: 開発部門専用のフォルダにアクセスできる権限。

• RoleBinding（特定の社員にフォルダ権限を割り当て）: この権限を「開発部門の山田さん」に割り当てます。

• 適用範囲: 開発部門内のフォルダに限り、この権限でアクセス可能になります。他の部門には影響しません。

2. ClusterRole + ClusterRoleBinding（全社共通のフォルダと全社に適用される権限の組み合わせ）

• ClusterRole（会社全体でアクセスできるフォルダの権限）: 全社共通のフォルダにアクセスできる権限。

• ClusterRoleBinding（全社員にフォルダ権限を割り当て）: この権限を「全社員」に適用します。

• 適用範囲: 全社共通のフォルダが会社全体でアクセスできるようになり、どの部門でも同じ権限で利用できます。

3. ClusterRole + RoleBinding（会社全体で使える権限を特定部門のフォルダに適用）

• ClusterRole（会社全体でアクセスできるフォルダの権限）: 「セキュリティ資料」など、特別な権限が必要なフォルダにアクセスできる権限。

• RoleBinding（特定部門のメンバーにのみフォルダ権限を割り当て）: この権限を「セキュリティ部門の社員」にのみ適用します。

• 適用範囲: 会社全体で利用できる権限ですが、特定部門のフォルダ（セキュリティ部門）でのみ使えるように制限されています。

4. Role + ClusterRoleBinding（無効：部門専用フォルダの権限を全社に適用するのは不可能）

• Role（部門専用フォルダの権限）: 開発部門だけが使える権限。

• ClusterRoleBinding（全社にフォルダ権限を適用しようとする）: 開発部門のフォルダを全社員に適用しようとする。

• 適用範囲: 部門専用のフォルダ権限を全社に適用することは不可能なので、この組み合わせは無効です。

---

まとめ

• Role + RoleBinding: 部門専用フォルダを特定の部門内でのみ使えるようにする。

• ClusterRole + ClusterRoleBinding: 全社共通フォルダを会社全体で使えるようにする。

• ClusterRole + RoleBinding: 会社全体の権限を持つフォルダを、特定の部門の社員にだけ適用する。

• Role + ClusterRoleBinding: 不可能な組み合わせ。部門専用フォルダの権限を全社に適用するのはできない。

このように、特定のフォルダ（Namespace）や会社全体のフォルダに、柔軟に権限を設定する仕組みがRBACの組み合わせです。