OpenShift

ブログ・コミュニティ

HOMEデベロッパー向けブログ・コミュニティ SCSK技術者ブログ第1回：OpenShift権限管理入門：ユーザー作成直後の初期権限とプロジェクト作成制御

カテゴリー

アーカイブ

第1回：OpenShift権限管理入門：ユーザー作成直後の初期権限とプロジェクト作成制御

2026

05月

11日

OpenShift権限管理入門 SCSK技術者ブログ

こんにちは、SCSKの石川です。
Red Hat OpenShiftを導入・運用する際、権限管理は避けては通れない課題です。「最小権限の原則」に基づいて必要最小限の権限を付与することが理想ではありますが、実際に運用するとなると、「どのチームにどの程度の権限を与えるのか」を決めるのが悩ましいところです。このブログシリーズでは、権限管理に焦点を当ててベストプラクティスを探っていきます。

シリーズ予定

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

はじめに

これまでOpenShiftの案件に携わり、グループやユーザーの作成、権限の設定を一連の流れで進めてきましたが、作成直後のユーザーが具体的に何ができるのか、改めて注目する機会は少なかったかもしれません。そこでまず、その点を整理することにしました。

１．ユーザを作成する

最初に、HTPasswdアイデンティティ―プロバイダーを使用してユーザを登録します。

# htpasswdファイルを作成
$ htpasswd -b -B -c custom-htpasswd ocpuser01 ocpuser01
$ htpasswd -b -B custom-htpasswd appuser01 appuser01

# htpasswdシークレットを作成
# oc create secret generic custom-htpasswd --from-file=htpasswd=custom-htpasswd -n openshift-config
secret/custom-htpasswd created

２．OAuthカスタムリソースを設定する

作成したhtpasswdファイルをOAuthカスタムリソースに登録します。

# バックアップを取得
# CURRENT_DATETIME=$(date '+%Y%m%d')
# oc get oauth cluster -o yaml > oauth-cluster_${CURRENT_DATETIME}.yaml

# OAuthカスタムリソースを設定
# oc patch oauth cluster --type='json' -p='[{"op": "add", "path": "/spec/identityProviders/-", "value": {"name": "custom-htpasswd_provider", "mappingMethod": "claim", "type": "HTPasswd", "htpasswd": {"fileData": {"name": "custom-htpasswd"}}}}]'
oauth.config.openshift.io/cluster patched

# OAuth設定を確認
# oc get oauth cluster -o yaml
apiVersion: config.openshift.io/v1
kind: OAuth
・・・
spec:
  identityProviders:
  - htpasswd:
      fileData:
        name: htpasswd
    mappingMethod: claim
    name: custom-htpasswd_provider
    type: HTPasswd

POD状況を確認します。

# oauth-openshift PODの再作成が完了するまでしばらく待つ
# oc get pod -n openshift-authentication -w

# authentication クラスタ―オペレーターのステータスを確認
# oc get co authentication
NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication   4.14.51   True        False         False      51m

３．グループを作成してユーザを追加する

本ブログにおいては、グループが必須ではありませんが、権限は通常、個々のユーザーではなくグループに付与することで、ユーザーの追加や削除が容易になり、ポリシーの一元管理が可能になるため、グループを作成します。

# グループ作成、ユーザ追加
# oc adm groups new ocpteam01 ocpuser01
group.user.openshift.io/ocpteam01 created

# oc adm groups new appteam01 appuser01
group.user.openshift.io/appteam01 created

# oc get group
NAME        USERS
appteam01   appuser01
ocpteam01   ocpuser01

# 作成したユーザでログインを確認
$ oc login -u ocpuser01 -p ocpuser01 https://api.cluster-xxxx:6443
WARNING: Using insecure TLS client config. Setting this option is not supported!
Login successful.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

$ oc whoami
ocpuser01

４．作成直後のユーザの権限を確認する

作成したばかりのユーザは、どのプロジェクトにも所属しておらず、権限を何も持っていません。但し厳密には、クラスタレベルのデフォルト権限（system:authenticated や system:authenticated:oauth 関連）により、一部のクラスタスコープリソースの操作を行うことができます（例えば、$ oc get sc）。

#ユーザはどのプロジェクトにも所属していない
$ oc projects
You are not a member of any projects. You can request a project to be created with the 'new-project' command.

# ポッド情報は取得できない
$ oc get pod
Error from server (Forbidden): pods is forbidden: User "ocpuser01" cannot list resource "pods" in API group "" in the namespace "default" 

# StorageClass情報は取得できる
oc get sc
NAME                                             PROVISIONER                             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage                              rhpd/nfs                                Delete          Immediate              false                  48m

# プロジェクトを作成することはできる
$ oc new-project ocpuser01-prj01
Now using project "ocpuser01-prj01" on server "https://api.cluster-xxx:6443".

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

５．なぜプロジェクトを作成できるのか

作成直後のユーザーがプロジェクトを作成できるのは、self-provisionerクラスターロールがsystem:authenticated:oauth仮想グループに付与されているためです。このロールは、projectrequestsおよびprojectrequests.project.openshift.ioリソースのcreate権限を持ち、プロジェクトを作成することができます。

# self-provisioner クラスターロール の情報を確認
# oc describe clusterrole self-provisioner
Name:         self-provisioner
Labels:       
Annotations:  openshift.io/description: A user that can request projects.
              rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources                             Non-Resource URLs  Resource Names  Verbs
  ---------                             -----------------  --------------  -----
  projectrequests                       []                 []              [create]
  projectrequests.project.openshift.io  []                 []              [create]

# self-provisioners クラスターロールバインディングの情報を確認
# oc describe clusterrolebindings self-provisioners
Name:         self-provisioners
Labels:       
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  self-provisioner
Subjects:
  Kind   Name                        Namespace
  ----   ----                        ---------
  Group  system:authenticated:oauth

system:authenticated:oauthは、OAuth認証（例: HTPasswd、LDAP、OpenID Connect）でログインしたユーザーを含む仮想グループです。HTPasswdプロバイダで認証されたユーザーはこのグループに暗黙的に所属し、self-provisioner権限を継承します。
一方、system:authenticatedはすべての認証済みユーザーを含む広範なグループで、両者の違いによりself-provisioner権限はOAuth認証ユーザーに限定されます。

# ocpuser01ユーザは custom-htpasswd_provider:ocpuser01アイデンティティで認証されている
# oc get user ocpuser01 -o yaml
apiVersion: user.openshift.io/v1
groups: null
identities:
- custom-htpasswd_provider:ocpuser01
kind: User
metadata:
  creationTimestamp: "2025-05-19T05:57:28Z"
  name: ocpuser01
  resourceVersion: "52097"
  uid: 6adc8fea-261d-4273-9608-9703801c0dec

*1 oc new-projectは一般ユーザ向けです。プロジェクト作成時にAdminロールが自動付与されますが、システム予約名（例: `openshift-`や`kube-`）は使用できません。
一方、oc adm new-projecはクラスタ管理者向けです。ノードセレクタ―などの詳細設定が可能で、システム予約名のプロジェクトも作成できます。

*2 デフォルト権限の確認には以下を使用します。
basic-userクラスターロールは、例えばStorageClassリソースのgetやlistを許可します。

$ oc auth can-i --list --as=<ユーザ名>
$ oc get clusterrolebindings -o wide | grep system:authenticated
$ oc describe clusterrole basic-user

６．ユーザのプロジェクト作成を制限する

OpenShiftでは、デフォルトの設定ではすべてのOAuth認証済みユーザーが自由にプロジェクトを作成できてしまいます。本番環境では、セキュリティや管理の観点から、プロジェクト作成の権限を特定のユーザーやグループに限定したいケースがよくあります。そこで、セルフプロビジョニング機能を無効化することで、プロジェクト作成を適切に制限します。
さらに、rbac.authorization.kubernetes.io/autoupdateアノテーションをfalseに設定することで、APIサーバーの再起動時にカスタマイズした設定が自動的に上書きされないようにします。これにより、より安全で管理しやすい運用環境を構築できます。

# self-provisionersクラスタロールバインディングの設定内容を確認
# oc describe clusterrolebindings self-provisioners
Name:         self-provisioners
Labels:       
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  self-provisioner
Subjects:
  Kind   Name                        Namespace
  ----   ----                        ---------
  Group  system:authenticated:oauth

# 念のため、作業前にバックアップを取得
# oc get clusterrolebindings.rbac self-provisioners -oyaml > self-provisioners.yaml.bk

# self-provisionersクラスタロールバインディングの設定を変更する
# oc annotate clusterrolebinding/self-provisioners \
  --overwrite rbac.authorization.kubernetes.io/autoupdate=false
clusterrolebinding.rbac.authorization.k8s.io/self-provisioners annotated
# oc patch clusterrolebinding.rbac self-provisioners \
  -p '{"subjects": null}'
clusterrolebinding.rbac.authorization.k8s.io/self-provisioners patched

patch適用後にself-provisionersクラスタロールバインディングの設定内容を確認

rbac.authorization.kubernetes.io/autoupdate はfalseになっている
Subjectsからは、 Group system:authenticated:oauthが削除されている

# oc describe clusterrolebindings self-provisioners
Name:         self-provisioners
Labels:       
Annotations:  rbac.authorization.kubernetes.io/autoupdate: false
Role:
  Kind:  ClusterRole
  Name:  self-provisioners
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------

動作確認

# プロジェクトは作成できなくなっている
$ oc whoami
ocpuser01

$ oc new-project ocpuser01-prj02
Error from server (Forbidden): You may not request a new project via this API.

*1 セルフプロビジョニングを無効化した後、特定のグループやユーザーにプロジェクト作成権限を付与したい場合は、self-provisionerクラスターロールを特定のグループにバインドするClusterRoleBindingを作成します。

７．作成直後のユーザーができること

OpenShiftでユーザーを作成した直後は、どのプロジェクトにも所属していない状態ですが、以下の操作が可能です。

クラスタスコープリソースの参照 デフォルトで付与されているbasic-userクラスターロールにより、StorageClassなどの一部のクラスタスコープリソースを参照できます（例: oc get sc）。
プロジェクトの作成
self-provisionerクラスターロールがsystem:authenticated:oauth仮想グループに付与されているため、 OAuth認証済みユーザーはプロジェクトを自由に作成できます。これにより、ユーザーは自身の作業環境をすぐに構築できますが、本番環境ではこの権限を制限することが一般的です

これらのデフォルト権限を把握することは、権限管理の基本を理解する第一歩です。実際の運用では「誰が何をできるのか」を明確に把握しておくことが重要です。たとえば、プロジェクト作成の自由度が高すぎると、意図しないリソースの増加やセキュリティリスクが生じる可能性があります。そこで、セルフプロビジョニングを無効化するなどの対策を通じて、運用環境をより安全に効率的に管理できます。

次回は、Adminロールの具体的な権限を掘り下げます。特に、Adminロールでアプリケーションのデプロイ作業が可能かどうかを中心に、実際の運用でのポイントを整理します。

OpenShift 4.17でNTP設定変更を無停止化する｜Node Disruption PolicyとMachineConfigの検証

第2回：OpenShiftのAdminロールとは？できること・できないことを実践解説

Why OpenShift

製品概要

製品ラインナップ

OpenShiftのライフサイクル

SCSKの強み

導入支援・サポート

開発者向け機能

OpenShift Documentaition

OpenShiftリリースノート

APIリファレンス

OpenShift Security