クラウドネイティブスクエア

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

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

はじめに

これまで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:       <none>
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:       <none>
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:       <none>
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:       <none>
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ロールでアプリケーションのデプロイ作業が可能かどうかを中心に、実際の運用でのポイントを整理します。