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

前回は、特定のプロジェクト内での「Admin」権限を確認しました。今回は、OpenShiftの権限付与の仕組みである RoleBinding（特定プロジェクトのみ）と ClusterRoleBinding（クラスタ全体）の違いに焦点を当てます。もし、Adminロールを ClusterRoleBinding を使ってユーザに付与すると、そのユーザはどのような権限を持つことになるのでしょうか。

シリーズ予定

• 第1回：OpenShift権限管理入門：ユーザー作成直後の初期権限とプロジェクト作成制御
• 第2回：OpenShiftのAdminロールとは？できること・できないことを実践解説
• 第3回：OpenShiftのClusterRoleBindingとは？Adminロールをクラスタ全体に付与した場合の影響
• 第4回：OpenShiftのcluster-admin権限を解説：RoleBindingとClusterRoleBindingの違い
• 第5回：OpenShiftのカスタムロール設計：最小権限で運用するための作成ポイント
• 第6回：OpenShiftのRBAC設計：チームごとに適切な権限を付与する考え方
• 第7回：OpenShiftの権限管理を継続改善する：RBAC監査と見直しのポイント

目次

1. ClusterRoleBindingとは
2. ユーザにAdminロールをClusterRoleBindingで付与する
3. 既存の全プロジェクトへのアクセス確認
4. 新規作成されたプロジェクトへのアクセス確認
5. クラスタスコープリソース（Node, PV）へのアクセス確認
6. アクセス権限が強力であることへの注意
7. まとめ

１．ClusterRoleBindingとは

通常、権限付与には RoleBinding を使用します。「誰が」「どのプロジェクトで」権限を持つかを紐づけるものです。
それに対して ClusterRoleBinding は、「誰が」「クラスタ全体で（すべてのプロジェクトで）」権限を持つかを定義します。

２．ユーザにAdminロールをClusterRoleBindingで付与する

検証用ユーザ ocpadmin01 を作成し、Adminロールをクラスタ全体に対して付与します。
※この操作には cluster-admin 権限が必要です。

# ユーザ作成
$ oc create user ocpadmin01
user.user.openshift.io/ocpadmin01 created

# ClusterRoleBindingの作成
$ oc adm policy add-cluster-role-to-user admin ocpadmin01
clusterrole.rbac.authorization.k8s.io/admin added: "ocpadmin01"

add-role-to-user ではなく、add-cluster-role-to-user コマンドを使用している点に注目してください。

３．既存の全プロジェクトへのアクセス確認

ocpadmin01 ユーザでログインし、自分が作成していないプロジェクトへのアクセスを試みます。

# ログイン
$ oc login -u ocpadmin01
Console URL: https://api.xxx...
Authentication required for https://api.xxx... (openshift)
Username: ocpadmin01
Password:
Login successful.

You have access to 83 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "ocp-prj01".

# プロジェクト一覧の取得
$ oc projects
 (全プロジェクトが表示されます)

# 他人のプロジェクトのリソース操作
$ oc get pods -n openshift-console
(Pod一覧が表示されます)

$ oc delete pod <pod-name> -n openshift-console
(削除成功)

本来アクセスできないはずの openshift-console プロジェクトなどのシステムプロジェクトに対しても、Admin権限（作成・削除・更新）を行使できることが確認できました。

４．新規作成されたプロジェクトへのアクセス確認

この権限の強力な点は、「将来作成されるプロジェクト」にも自動的に適用されることです。
別の管理者ユーザで新しいプロジェクト future-project を作成した後、ocpadmin01 からアクセスしてみます。

# (別端末) プロジェクト作成
$ oc new-project future-project
  ...

# (検証ユーザ) アクセス確認
$ oc get pods -n future-project
No resources found in future-project namespace. (アクセス可能)

RoleBindingであればプロジェクト作成のたびに付与が必要ですが、ClusterRoleBindingであればその手間はありません。

５．クラスタスコープリソース（Node, PV）へのアクセス確認

では、このユーザは「OpenShift管理者（cluster-admin）」と同じなのでしょうか。
ノード情報の取得を試みます。

# ノード情報の取得
$ oc get nodes
Error from server (Forbidden): nodes is forbidden: User "ocpadmin01" cannot list resource "nodes" in API group "" at the cluster scope

失敗しました。ここが非常に重要なポイントです。
Adminロールをクラスタワイドで付与しても、Adminロール自体の定義（PodやServiceの操作権限）が変わるわけではありません。
Adminロールには「Nodeを参照する」という権限が含まれていないため、たとえ全プロジェクトに適用されたとしても、プロジェクト外のリソースであるNodeやPersistentVolume（PV）は操作できません。

６．アクセス権限が強力であることへの注意

「Nodeが見えないなら安全か」というと、そうではありません。
このユーザは、openshift- で始まるシステム上重要なプロジェクト内のリソースも自由に削除・変更できます。誤って重要なPodやSecretを削除すれば、クラスタ障害を引き起こす可能性があります。

また、「Nodeのリソースが見えない」＝「ノードの管理ができない」 という点も重要です。例えば、ノードのスケジュール設定（Cordon/Uncordon）や、ノードごとのログ調査などは、この ocpadmin01 権限では実施できません。あくまで「アプリケーション運用者」としての全能であり、「インフラエンジニア」としての全能ではありません。

７．まとめ

AdminロールをClusterRoleBindingで付与するということは、「全プロジェクトの管理者（Project Admin for All）」になることであり、「プラットフォーム管理者（Platform Admin）」になることとは異なります。

• できること: 既存および将来の全プロジェクト（openshift-xxxなども含む）内でのリソース操作、RoleBinding管理。
• できないこと: ノード操作、PV作成、CRD作成、ResourceQuota変更（前回同様）。

運用チームのメンバーであっても、安易にこの権限を付与するのではなく、必要なプロジェクトに対してのみRoleBindingを行うか、後述するカスタムロールの検討を推奨します。

次回は、cluster-adminをRoleBindingとClusterRoleBindingで付与した時の違い整理します。