OpenShiftの権限管理をわかりやすく第2回 Adminロールで何ができるのか

2026.04.13

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

前回は、作成直後のユーザが持つデフォルトの権限について解説しました。今回は、実際のプロジェクト運用で頻繁に利用される「Admin（プロジェクト管理者）」ロールについて深掘りします。「管理者」という名前がついていますが、OpenShiftのAdminロールは「万能」ではありません。今回はその境界線を確認します。

シリーズ予定

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

Adminロールをユーザに付与する
Adminロールの定義を確認する
プロジェクト内リソースの操作（Pod,Deployment,Service）
他ユーザへの権限付与(RoleBindingの作成)
ResourceQuota(リソース制限)
ノード情報の参照を試みる
Admin権限でのアプリケーションデプロイ可否チェック
まとめ

１．Adminロールをユーザに付与する

まず、検証用のユーザ ocpuser01 を作成し、プロジェクト ocp-prj01 に対してAdminロールを付与します。

# ユーザとプロジェクトの作成
$ oc new-project ocp-prj01
Now using project "ocp-prj01" on server ...

You can add applications to this project with the 'new-app' command. For example, try:

    oc new-app rails-postgresql-example

to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:

    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost serve-hostname


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


# Adminロールの付与（RoleBinding作成）
$ oc adm policy add-role-to-user admin ocpuser01 -n ocp-prj01
clusterrole.rbac.authorization.k8s.io/admin added: "ocpuser01"

これで、ocpuser01は ocp-prj01 内での管理者となりました。

2．Adminロールの定義を確認する

操作を行う前に、Adminロールがどのような権限を持っているか定義を確認します。

# Adminロールの確認
$ oc describe clusterrole admin
Name:         admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources                                                        Non-Resource URLs  Resource Names                                                     Verbs
  ---------                                                        -----------------  --------------                                                     -----
 ...
  pods                                                             []                 []                                                                 [create delete deletecollection patch update get list watch]
  deployments.apps                                                 []                 []                                                                 [create delete deletecollection patch update get list watch]
  rolebindings                                                     []                 []                                                                 [create delete deletecollection get list patch update watch]
  roles                                                            []                 []                                                                 [create delete deletecollection get list patch update watch]

pods や deployments だけでなく、rolebindingsに対する権限や、多岐にわたるリソースに対する権限を持っていることが分かります。これが Adminロールとedit ロールの大きな違いです。

3．プロジェクト内リソースの操作

Adminユーザでログインし、一般的なリソース操作を試みます。

# ユーザの切り替え
$ oc login -u ocpuser01
Console URL: https://api.xxx...
Authentication required for https://api.xxx... (openshift)
Username: ocpuser01
Password:
Login successful.

You have one project on this server: "ocp-prj01"

Using project "ocp-prj01".


# 現在のユーザの確認
$ oc whoami
ocpuser01


# Podの作成
$ oc run nginx --image=nginx
pod/nginx created


# Podの削除
$ oc delete pod nginx
pod "nginx" deleted

$ oc get pod
No resources found in ocp-prj01 namespace.

4．他ユーザへの権限付与(RoleBindingの作成)

プロジェクト管理者の重要な役割として、「チームメンバーへの権限付与」があります。Adminロールを持つユーザは、自分のプロジェクト内に限り、他のユーザを招待（RoleBindingを作成）できます。

# アプリケーション開発担当者(devuser01)にedit権限を付与
$ oc adm policy add-role-to-user edit devuser01 -n ocp-prj01
clusterrole.rbac.authorization.k8s.io/edit added: "devuser01"

OpenShift管理者に依頼することなく、プロジェクト管理者が自律的にチームメンバーの権限管理を行うことができます。

但し、作成済みユーザに対するプロジェクトレベルの権限のみ付与可能であり、ユーザの作成やクラスタレベルの権限を付与することはできません。

$ oc get user
Error from server (Forbidden): users.user.openshift.io is forbidden: User "ocpuser01" cannot list resource "users" in API group "user.openshift.io" at the cluster scope

5．ResourceQuota（リソース制限）の変更を試みる

ここからが本題です。プロジェクト管理者はプロジェクト内の「すべて」を管理できるのでしょうか？ResourceQuota（クォータ）の確認・作成・削除を試みます。

# 現在のResourceQuota確認（取得）
$ oc get resourcequota
No resources found in ocp-prj01 namespace.


# 新たなResourceQuotaの作成を試みる
$ oc create quota test-quota --hard=pods=10,cpu=4,memory=8Gi
error: failed to create quota: resourcequotas is forbidden: User "ocpuser01" cannot create resource "resourcequotas" in API group "" in the namespace "ocp-prj01"


# (仮に存在したとして）ResourceQuotaの削除を試みる
$ oc delete resourcequota test-quota
Error from server (Forbidden): resourcequotas "test-quota" is forbidden: User "ocpuser01" cannot delete resource "resourcequotas" in API group "" in the namespace "ocp-prj01"

失敗しました。現在のResourceQuotaを確認（get）することは権限的に可能ですが（今回は対象が存在しないため何も表示されませんが）、新規作成（create）や削除（delete）を行う権限は持っていません。Adminロールはプロジェクト内のリソース管理者ですが、リソース消費量の上限（ResourceQuota）を作成・変更・削除する権限は持っていません。これは、マルチテナント環境において1つのプロジェクトがリソースを独占しないよう、OpenShift管理者（Cluster Admin）によって制御されるべき領域だからです。

6．ノード情報の参照を試みる

次に、クラスタ全体の情報であるノード（Node）の情報を見ることができるかを試します。

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

これも失敗しました。Adminロールはあくまで「Namespace（プロジェクト）」の中に閉じ込められた管理者であり、クラスタレベルのリソース（Node, PersistentVolumeなど）を参照・操作することはできません。

7．Admin権限でのアプリケーションデプロイ可否チェック

実際の開発現場では、「Admin権限があれば何でもデプロイできる」と思われがちですが、実は多くのハードルがあります。一般的なアプリケーションデプロイのシナリオにおいて、Admin権限だけで完結するか整理しました。

シナリオ別権限チェックリスト

#	シナリオ	必要な操作	Admin権限で可能か	必要な追加権限 (依頼先)
1	非rootでPod起動	一般的なWebアプリ等のPod起動 (Restricted SCC)	〇可能	不要
2	特権SCC利用	`anyuid` (root起動), `hostaccess` 等のSCCをSAに付与	× 不可	OpenShift管理者 (SCCのuse権限)
3	カスタムSCC作成	独自のSCCを作成し、SAに付与	× 不可	OpenShift管理者 (SCCのcreate権限)
4	ClusterRoleBindingの作成	SAに対してクラスタ全体での権限(ClusterRoleBinding)を付与	× 不可	OpenShift管理者 (ClusterRoleBindingのcreate権限)
5	CRD作成	Custom Resource Definition の作成	× 不可	OpenShift管理者 (CRDのcreate権限)
6	PV作成	PersistentVolume (PV) の静的作成	× 不可	OpenShift管理者 (PVのcreate権限) ※PVCによる動的確保ならAdminで可能
7	Operator導入	Operatorをインストール (Subscription, CR管理)	△ 部分的に可能	Namespace-scoped OperatorGroupが事前構成済の場合のみ。標準構成ではOpenShift管理者が必要
8	他Project参照	他プロジェクトのリソースにアクセス	× 不可	対象プロジェクトの管理者 (RoleBinding追加)
9	Ingress/Route	Route作成 (HTTP/HTTPS)	〇可能	証明書管理等はSecret権限があれば可
10	ビルド実行	BuildConfig, ImageStreamでのビルド	〇可能	ビルド自体は可能 (特権SCCが必要なビルドは不可)
11	NetworkPolicy	通信制御ルールの作成	〇可能	不要

ポイント

* 「特権」が必要なときはAdminでは無理: root ユーザでの実行（anyuid）や、ホストOSの領域マウント（hostaccess）など、セキュリティリスクが高い操作はAdminロールでは許可されていません。これらはOpenShift管理者に依頼する必要があります。

* 「クラスタ全体」に関わるものは無理: CRDやPV（静的）はクラスタ全体のリソースであるため、特定のプロジェクト管理者には触らせません。

8．まとめ

今回の検証で、Adminロールの境界線が明確になりました。

操作カテゴリ	具体的なアクション	Admin権限で可能か
アプリ管理	Pod, Service, Deployment, Secret, ConfigMap, LimitRange 等の作成・削除	〇可能
チーム管理	プロジェクト内でのRoleBinding作成（メンバ追加）	〇可能
リソース制限	ResourceQuotaの作成・変更・削除	× 不可（Forbidden）
基盤参照	Node, PV情報の参照	× 不可（Forbidden）
高度なデプロイ	特権SCC利用、CRD作成	× 不可（Forbidden）

* Secretの管理: Adminロールは Secretの読み書きが可能です。これはデータベースのパスワードやAPIキーを管理するために必須の権限ですが、同時に「Admin権限を持つユーザは、そのプロジェクト内のあらゆる機密情報を見ることができる」ことを意味します。不要なメンバーにAdmin権限を渡さないことがセキュリティ上重要です。

* ResourceQuotaの制約: ResourceQuota は、OpenShift管理者が「このプロジェクトにはこれだけのリソース(CPU/メモリ)を与える」と定める契約のようなものです。そのため、プロジェクト管理者が自分でこれを変更できてしまうと、リソース管理が破綻してしまいます。これが権限が分離されている理由です。

次回は、Adminロールを ClusterRoleBinding で付与するとどうなるかを確認します。