HOMEデベロッパー向け ブログ・コミュニティ SCSK技術者ブログ 第4回：OpenShiftのcluster-admin権限を解説：RoleBindingとClusterRoleBindingの違い
第4回：OpenShiftのcluster-admin権限を解説：RoleBindingとClusterRoleBindingの違い
こんにちは、SCSKの石川です。
OpenShiftには cluster-admin というroot権限が存在します。これを付与すれば何でもできると思われがちですが、実は「付与の仕方（Bindingの種類）」によって挙動が変わります。誤解しやすい挙動のため、今回はその違いを整理します。
シリーズ
- 第1回：OpenShift権限管理入門：ユーザー作成直後の初期権限とプロジェクト作成制御
- 第2回：OpenShiftのAdminロールとは？できること・できないことを実践解説
- 第3回：OpenShiftのClusterRoleBindingとは？Adminロールをクラスタ全体に付与した場合の影響
- 第4回：OpenShiftのcluster-admin権限を解説：RoleBindingとClusterRoleBindingの違い
- 第5回：OpenShiftのカスタムロール設計：最小権限で運用するための作成ポイント
- 第6回：OpenShiftのRBAC設計：チームごとに適切な権限を付与する考え方
- 第7回：OpenShiftの権限管理を継続改善する：RBAC監査と見直しのポイント
目次
- ClusterRoleBindingとは
- パターンA：ClusterRoleBindingで付与した場合
- パターンB：RoleBindingで付与した場合
- パターンBでResourceQuotaを変更してみる
- パターンBでResourceQuotaを変更してみる
- パターンBでCRDやNode操作を試みる
- Webコンソールでの見え方の違い
- どちらを使うべきか・まとめ
1.ClusterRoleBindingとは
cluster-admin ロールの定義は非常にシンプルかつ強力です。
$ oc describe clusterrole cluster-admin
Name: cluster-admin
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
*.* [] [] [*]
[*] [] [*]
「すべてのAPIグループの、すべてのリソースに対して、すべての操作が可能」という定義です。
2.パターンA：ClusterRoleBindingで付与した場合
これが一般的な「OpenShift管理者」の作り方です。
$ oc adm policy add-cluster-role-to-user cluster-admin <user>
この場合、ユーザは文字通り「クラスター全体を統括する権限」を持ちます。ノードの削除、CRDの作成、全プロジェクトの操作など、制約はありません。
3.パターンB：RoleBindingで付与した場合
この最強のロールを「特定のプロジェクト内だけ（RoleBinding）」で付与するとどうなるでしょうか。
検証用ユーザ local-super-user を作成し、ocp-prj02 に対してのみ cluster-admin ロールを付与します。
# RoleBindingでcluster-adminを付与 $ oc adm policy add-role-to-user cluster-admin local-super-user -n ocp-prj02 clusterrole.rbac.authorization.k8s.io/cluster-admin added: "local-super-user"
このユーザは ocp-prj02 の中で「スーパーユーザ」として振る舞います。
4.パターンBでResourceQuotaを変更してみる
第2回で、通常のAdminロールでは ResourceQuota の変更ができませんでした。
今回の local-super-user はどうでしょうか。
# ユーザ切り替え $ oc login -u local-super-user Login successful. # ResourceQuotaの作成 $ oc create resourcequota compute-resources --hard=requests.cpu=10,requests.memory=10Gi,limits.cpu=20,limits.memory=20Gi resourcequota/compute-resources created $ oc get resourcequotas compute-resources NAME REQUEST LIMIT AGE compute-resources requests.cpu: 0/10, requests.memory: 0/10Gi limits.cpu: 0/20, limits.memory: 0/20Gi 12s
成功しました。
これが「プロジェクトにバインドされたcluster-admin」の最大の特徴です。この権限を持つユーザは、そのプロジェクト内に限り、Adminロールでは禁止されていたResourceQuotaの作成・変更・削除が可能になります。
なぜ変更できるのか？
cluster-admin ロールは verbs: ["*"], resources: ["*"] （全てのリソースに対して全ての操作が可能）というルールを持っているからです。RoleBindingで特定のプロジェクトに紐づけられた場合、プロジェクト内のリソース（ResourceQuota はプロジェクトリソース）に対して有効になります。一方、admin ロールにはそもそも ResourceQuota を編集するルールが含まれていません。
5.パターンBでResourceQuotaを変更してみる
SCC権限の付与はどうでしょう。
$ oc adm policy add-scc-to-user anyuid -z default -n ocp-prj02 Error from server (Forbidden): clusterrolebindings.rbac.authorization.k8s.io "system:openshift:scc:anyuid" is forbidden: User "local-super-user" cannot get resource "clusterrolebindings" in API group "rbac.authorization.k8s.io" at the cluster scope
失敗しました。それでは、直接 RoleBinding リソースを作成して付与してみましょう。
$ oc create rolebinding default-anyuid-binding \ --clusterrole=system:openshift:scc:anyuid \ --serviceaccount=ocp-prj02:default -n ocp-prj02 rolebinding.rbac.authorization.k8s.io/default-anyuid-binding created
今度は付与できました。
なぜ oc adm policy コマンドは失敗し、RoleBinding の作成は成功したのか？
oc adm policy add-scc-to-user でエラーが発生した理由は、このコマンドが内部処理として既存の ClusterRoleBinding system:openshift:scc:anyuid を参照（GET）しようとするためです。local-super-user は対象プロジェクト内では全能ですが、クラスタスコープのリソースにアクセスする権限がないため、この内部処理の段階でエラーとなりました。
一方で、OpenShiftのRBACは権限のエスカレーション（昇格）を防ぐように厳密に設計されているため、通常のプロジェクト管理者（admin ロールを持つユーザー）であっても、自分に与えられていないSCCの権限を他者にバインドして付与することは仕様上許可されていません。
それにもかかわらず手動での RoleBinding 作成が成功したのは、今回操作を行った「local-super-user」が、対象の ocp-prj02 プロジェクトに対して cluster-admin（スーパー管理者）特権をローカルバインディングとして付与されていたためです。プロジェクト内のすべてのリソースに対する完全な制御権限（あらゆるロールをバインドする権限を含む）を持っていたため、エスカレーションチェックに引っかかることなく、正当な権限としてバインディングを作成できました。
これにより、「ocp-prj02」プロジェクトの「default サービスアカウント（およびそのアカウントで実行されるPod）」が、同プロジェクト内でのみ anyuid SCC を使用して特権プロセスを起動する権限を持ってしまう結果となりました。意図した動作であれば問題ありませんが、意図しない動作であれば注意が必要です。
サービスアカウントやSCCの利用に関しては、維持保守およびセキュリティの観点から、常に**『最小権限の原則』**を踏まえた運用設計を行っていくことが重要です。
今回は検証のため default サービスアカウントにSCCを付与しましたが、実運用では推奨されません。default を特権化すると、そのプロジェクトで動く他の無関係なPodまで特権を持ってしまうリスクがあります。SCCを付与する場合は、必ず「そのアプリケーション専用のサービスアカウント（例: my-app-sa）」を個別に作成し、そこにバインドする設計にしてください。
6.パターンBでCRDやNode操作を試みる
プロジェクト外の操作はどうでしょうか。
# ノード情報の取得 $ oc get nodes Error from server (Forbidden): nodes is forbidden: User "local-super-user" cannot list resource "nodes" in API group "" at the cluster scope
失敗しました。
たとえロール定義（Rules）に resources: ["*"] とあっても、RoleBinding で紐づけられている以上、操作できるのはNamespace内に存在するリソースに限定されます。NodeやCRDはNamespaceに属さない（クラスタスコープの）リソースであるため、操作できません。
7.Webコンソールでの見え方の違い
Webコンソール上では、この違いが少しわかりにくい場合があります。 「ユーザ管理」画面を見ると、どちらもロール名としては cluster-admin と表示されることがありますが、適用範囲（Namespace列）が「全プロジェクト（Cluster）」か「特定プロジェクト名」かで判別してください。
8.どちらを使うべきか・まとめ
対象プロジェクト内に限定されますが、ローカルcluster-admin（パターンB）では、通常の admin ロールでは不可能な以下の操作が可能になります。
- セキュリティ制約（SCC）の操作: プロジェクト内のサービスアカウントに対し、自身の判断で anyuid や privileged などの特権（SCC）を自由に紐付けることができます。
- リソース制限の操作: インフラ管理者が設定した ResourceQuota や LimitRange を自身で作成・修正・削除し、制限を上書きできます。
- NamespaceスコープのOperator導入: OperatorGroupが事前に構成されている場合、プロジェクト内に閉じたOperatorをインストール・管理できる可能性があります。ただし、OLMの構成に依存するため、すべてのケースで可能とは限りません。
- 未知のカスタムリソース（CR）の操作: 権限がワイルドカード（*）で付与されるため、標準リソースだけでなく、サードパーティ製ツールが持ち込んだ未知のCRに対しても完全な操作権限を持ちます。
これらを踏まえ、権限の付与方法は以下のように使い分けます。
| 付与方法 | 役割 | 推奨ユースケースと注意点 |
|---|---|---|
| ClusterRoleBinding | OpenShift管理者 | 【標準的な運用】 プラットフォーム運用・インフラ管理チーム専用。クラスター全体の維持管理のために、全権限が必要な場合のみ付与します。 |
| RoleBinding | プロジェクトのスーパー管理者 | 【例外的な運用】 開発環境などで、チームにOperatorの導入やQuota管理の裁量まで完全に委譲したい場合の最終手段。特権コンテナの起動リスクを伴うため、本番環境では原則使用しません。 |
※運用上の注意
マルチテナント環境において、開発チームやプロジェクトの責任者に付与する権限は、原則として標準の admin ロールで十分です。「ローカルcluster-admin」は権限エスカレーション（特権の自己付与）のリスクを伴うため、安易な付与は避けます。
また、要件によりSCC（anyuid等）を付与する必要がある場合でも、プロジェクトの default サービスアカウントは特権化せず、必ず「アプリケーション専用のサービスアカウント（例: my-app-sa）」を個別に作成して最小権限をバインドする設計を徹底します。
次回は、カスタムロールの作成と運用上の注意事項を見ていきたいと思います。
