ROSAのdedicated-adminについて調べてみた - 赤帽エンジニアブログ

こんにちは、Red Hatでソリューションアーキテクトをしている北村です。今回はROSA（Red Hat OpenShift on AWS）環境のdedicated-adminの権限について軽くまとめていきます。

dedicated-adminへの権限付与の仕組み

ROSAをインストールしたのちログインするとdedicated-adminsというGroupが存在しているのが確認できます。

$ oc get group
NAME               USERS
cluster-admins     cluster-admin
dedicated-admins

このdedicated-adminに紐づいているロールは以下の手順にてコンソール上で確認できます。

「ユーザー管理」→「グループ」→「dedicated-admins」→「ロールバインディング」

実際に確認いただくと分かりますが、dedicated-adminは大きく以下の方針でRoleが渡されています。

ClusterRoleBindingで、Cluster APIに関するRoleをclusterrole:dedicated-admins-clusterで付与
Projectごとにclusterrole:dedicated-admins-projectとclusterrole:adminを付与
- dedicated-admins-project：limitrangeやresourcequotaなどクラスター管理者が扱うリソースの操作権限
- admin：project作成者が持つ権限
いくつかのOpenShiftの管理Projectに対しては独自のroleを付与

ここで特徴的なのが、ProjectごとにClusteRroleをBindingしている点です。おそらく「ClusterRoleBindingでProject全体には付与したくないけど、ユーザーが作成したProjectに対してはより幅広い権限を持たせたい」といった目的があるのではないかと思います。しかしこの運用を行うためには、ユーザーがProjectを作成するたびにRoleBindingリソースをデプロイする必要がでてきます。

この運用を自動化するべく、ROSAやOSD（OpenShift Dedicated）には専用のOperatorとして「RBAC Permissions Operator」がインストールされています。

RBAC Permissions Operator

RBAC Permissions OperatorはROSA/OSDにプリインストールされているOperatorです。このOperatorはProjectに対するRoleBindingを管理しており、Projectの作成を検知して自動でRoleBindingの作成を実施してくれます。どのProjectにどんなRoleBindingをデプロイするのかは、カスタムリソースであるSubjectPermissionで定義します。（残念ながらROSAでは新たにSubjectPermissionを作成することはできません。）

まずSubjectPermissionリソースを確認してみましょう。dedicated-admins-projectとadminの付与については、dedicated-adminsで管理されています。

apiVersion: managed.openshift.io/v1alpha1
kind: SubjectPermission
metadata:
  name: dedicated-admins
  namespace: openshift-rbac-permissions
spec:
  subjectKind: Group
  subjectName: dedicated-admins
  clusterPermissions:
    - dedicated-admins-cluster
  permissions:
    - 
      clusterRoleName: dedicated-admins-project
      namespacesAllowedRegex: ".*"
      namespacesDeniedRegex: "(^kube$|^kube-.*|^openshift$|^openshift-.*|^default$|^redhat-.*)"
      allowFirst: true
    - 
      clusterRoleName: admin 
      namespacesAllowedRegex: ".*" 
      namespacesDeniedRegex: "(^kube$|^kube-.*|^openshift$|^openshift-.*|^default$|^redhat-.*)"
      allowFirst: true

subjectKindでGroup or Userを指定し、subjectNameにGroup名 or User名を指定。
permissionsでBindしたいClusterRoleの指定と、自動でRoleBindingをデプロイしたいNamespaceの条件を正規表現を使って指定。
- namespaceAllowedRegex：対象とするNamespaceの条件。ここでは全てのNamespaceを指定。
- namespacesDeniedRegex：対象外とするNamespaceの条件。ここではKubernetesやOpenShiftの管理系のプロジェクトを対象外としている。
- allowFirst：AllowedとDeniedの順序を指定。trueにすると「基本はAllowだけどDeniedに指定してるものは除く」というロジックでチェック。
clusterPermissions：こちらを指定することでClusterRoleBindingも自動で実施。

上記のリソースの結果、ユーザーがProjectを作成すると自動でRoleBindingが作成されます。

$ oc new-project rbac-test
$ oc get rolebinding -n rbac-test | grep dedicated-admins
admin-dedicated-admins                                            ClusterRole/admin                      4m11s
dedicated-admins-project-dedicated-admins                         ClusterRole/dedicated-admins-project   4m11s
dedicated-admins-project-system:serviceaccounts:dedicated-admin   ClusterRole/dedicated-admins-project   4m11s

作成されたリソース名は”{付与するRole名}-{SubjectPermission名}”になっていることがわかります。

dedicated-adminの権限

さて、自動でRoleが付与される仕組みがわかったところで、dedicated-adminの権限を見ていきましょう。

基本的にはほとんどcluster-adminが持つ権限と変わりません。ここではいくつか運用する上で差分がありそうなポイントをピックアップしてお伝えします。

MachineAutoscaler/MachineConfig関連の操作ができない
- ClusterのAutoscaling設定やMachineConfigの閲覧・編集は不可
インストールできるOperatorに制限がある
- openshift-operatorsProjectにデプロイ可能（＝全てのNamespacesで利用可能）なOperatorのみインストール可能
開発者に該当のRoleBinding(admin-dedicated-admins / dedicated-admins-project-dedicated-admins)を削除されると、Projectへのアクセスがままならなくなる
- ClusterRoleBindingでRole/RoleBindingの作成が付与されているので作り直すことは可能
別のユーザーやグループに対して自分より強い権限（cluster-admin）の付与は不可

Red Hatが提供するOperatorにおいては、PipelinesやServiceMeshなど、クラスターに閉じた運用がメインのものはopenshift-operatorsProjectにデプロイされるためdedicated-adminでもインストール可能です。

一方で、Advanced Cluster Management for Kubernetes OperatorやOpenShift Data Foundation Operatorのようにクラスター外のリソースをがっつり使うようなOperatorについては、個別にNamespace/OperatorGroupを作成する必要があるためインストールできません。

以上のような特性を持つことから、cluster-adminとdedicated-adminは以下のよう使い分けできるといいのではと思います。

開発チームに対してクラスターごと払い出している場合
- 開発環境においては開発チームメンバー（もしくはその一部）にdedicated-adminを払い出して、ある程度柔軟に操作できる仕組みにする
- インフラ運用者はcluster-adminの権限を利用
  - インフラコストにシビアにいくならリーダー層のみcluster-admin、その他のメンバはdedicated-adminを利用
開発チームに対してProjectを払い出している場合
- LimitrangeやResourceQuotaが操作できるため開発者に対するdedicated-adminの付与は不可
- インフラ運用者はcluster-adminの権限を利用
  - インフラコストにシビアにいくならリーダー層のみcluster-admin、その他のメンバはdedicated-adminを利用