OpenShiftの権限管理をわかりやすく　第4回 cluster-adminをRoleBindingとClusterRoleBindingで付与した時の違い

2026.04.27

こんにちは、SCSKの石川です。

OpenShiftには cluster-admin というroot権限が存在します。これを付与すれば何でもできると思われがちですが、実は「付与の仕方（Bindingの種類）」によって挙動が変わります。誤解しやすい挙動のため、今回はその違いを整理します。

シリーズ予定

第1回：作成直後のユーザの権限
第2回：Adminロールの権限　
第3回：ClusterRoleBindingでAdminロールを付与したユーザの権限　
第4回：Cluster-AdminロールをRoleBindingとClusterRoleBindingで付与した時の違い（本記事）
第5回：カスタムロール作成のコツと注意点
第6回：各チームへの適切な権限付与
第7回：権限管理の継続的な見直し

cluster-adminロールとは
パターンA：ClusterRoleBindingで付与した場合
パターンB：RoleBindingで付与した場合
パターンBでResourceQuotaを変更してみる
パターンBでSCC権限を付与してみる
パターンBでCRDやNode操作を試みる
Webコンソールでの見え方の違い
どちらを使うべきか・まとめ

１．cluster-adminロールとは

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でSCC権限を付与してみる

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）」を個別に作成して最小権限をバインドする設計を徹底します。

次回は、カスタムロールの作成と運用上の注意事項を見ていきたいと思います。