OpenShift Cluster Manager API Token って？

私の中では、ROSAのクラスタを操作するときに必要なトークンです。（他の用途でも使うのかも？）
多くの人が、Red Hat Hybrid Cloud Consoleから取得していると思います。

トークンをクラスタごとに分ける理由

多くの場合、自社のシステムのクラスタを構築するとき、以下のように本番と開発のクラスタを分けると思います。管理上、１つのRed Hat Accountに２つのクラスタを収めたくなりますが、ただ単にまとめ上げてしまうと、１つのトークンで本番と開発のクラスタを触れてしまうので、本番・開発環境の分離ができません。起きうる事故としては、「間違って本番クラスタをアップグレードしちゃった。ごめんね！😂」とかがあります。

なので、Red Hat Accountを分けるなどのアプローチが取られたりします。

組織で管理しているクラスタが少なければ、なんとかなるかもしれませんが、数十、数百となってくると死んでしまうかもしれません。来年には、日本でもROSA上でのHosted Control Plane機能もGAになるのでしょうから、もっとクラスタをポンポン立てやすくなる気がします。

ROSAの中の人がどうやってクラスタの管理やそれらに紐づくサポートケースの管理をしているのかわからないですが、大元のRed Hat Accountから別れてしまうと、「A社でどれぐらい使っているかがわかりにくい🤑」とか「A社で類似の問い合わせが１００件バラバラと上がってきてつらい😣」とか起こるのかもしれません。しらんけど。

なので、目指すは以下のような構成。１つのRed Hat Accountで、権限が分離された複数のトークンを払い出せないかを試してみた。

結論から

まず、結論からですが、ただ単に作ったRed Hat Accountから複数のトークンを払い出すことはできない仕様となっているようです。なので、Red Hat Organization にユーザを追加し、そのユーザごとにトークンを払い出せば、権限も分離されるそうです。

本当かどうかを確認した

まずは、Red Hat Customer Portalのユーザー管理ページに飛びます。
そして、適当にユーザーを２つ作ります。

まずは、system_a_admin側での作業として、ROSAクラスタを作ります。

# system_a_admin で取得したトークンでログインする
rosa login --token="eyJ ...snip... "

# アカウントロールを作る
rosa create account-roles --mode auto

# OIDC　CONFIGを作る
rosa create oidc-config --mode auto

# オペレーターロールを作る
rosa create operator-roles --prefix ManagedOpenShift-HCP-ROSA --oidc-config-id 286u ...snip... 7hug --hosted-cp

# ROSAクラスタを作る
rosa create cluster --cluster-name rosa-system-a ¥
  --sts ¥
  --role-arn arn:aws:iam::68 ...snip... 92:role/ManagedOpenShift-HCP-ROSA-Installer-Role ¥
  --support-role-arn arn:aws:iam::68 ...snip... 92:role/ManagedOpenShift-HCP-ROSA-Support-Role ¥
  --worker-iam-role arn:aws:iam::68 ...snip... 92:role/ManagedOpenShift-HCP-ROSA-Worker-Role ¥
  --operator-roles-prefix ManagedOpenShift-HCP-ROSA ¥
  --oidc-config-id 286u ...snip... 7hug ¥
  --region us-east-1 ¥
  --version 4.14.5 ¥
  --replicas 3 ¥
  --compute-machine-type t3.xlarge ¥
  --machine-cidr 10.0.0.0/16 ¥
  --service-cidr 172.30.0.0/16 ¥
  --pod-cidr 10.128.0.0/14 ¥
  --host-prefix 23 ¥
  --private-link ¥
  --subnet-ids subnet-0b ...snip... 3e,subnet-03 ...snip... 1f,subnet-0e ...snip... bf ¥
  --hosted-cp

# 作っているクラスタの存在を確認
rosa list cluster
ID                                NAME           STATE       TOPOLOGY
286u ...snip... 0efd  rosa-system-a  validating  Hosted CP

続いて、system_b_admin側での作業。ここでは、system_b_adminのトークンを使って、system_a_adminが作ったクラスタが消せないことを確認します。

# system_b_admin で取得したトークンでログインする
% rosa login --token="eyJ ...snip... -ko"

# アカウント情報を確認
% rosa whoami | grep "Account UserName"
OCM Account Username:         system_b_admin@xxx.yyy

# 既存のクラスタ情報を参照
% rosa list cluster
ID                    NAME           STATE  TOPOLOGY
286u ...snip... 0efd  rosa-system-a  ready  Hosted CP

# クラスタを消してみる。めでたくForbiddendで弾かれる。
% rosa delete cluster --cluster rosa-system-a
? Are you sure you want to delete cluster rosa-system-a? Yes
E: Failed to delete cluster 286u ...snip... 0efd: Forbidden access to delete resource '286u ...snip... 0efd'

どういう仕様か？

中の人曰く以下とのこと。Red Hat Accountを開設したアカウントには組織管理者のロールがついているので、このアカウントから発行されたトークンを使うと、どのクラスタでも滅ぼせるが、今回作ったようなsystem_a_adminやsystem_b_adminのような子アカウントで発行したトークンを用いてクラスタを作れば、基本的な変更権限はそのトークンに紐づくみたい。

デフォルトのRBACポリシー
- OpenShift Cluster Manager は、基本的な RBAC ポリシーを暗黙的に適用して、初期設定の必要なく、ユーザーがクラスターのライフサイクルを管理するために必要な権限を持つようにします。
- すべての組織メンバーは、任意の組織メンバーによってプロビジョニングされたすべてのクラスターを表示できます。
- すべての組織メンバーは、組織に必要なクォータ/サブスクリプションがある限り、クラスタをプロビジョニングできます。
- クラスタをプロビジョニングしたユーザにはクラスタ所有者のロールが付与され、クラスタを管理し、削除することもできます。
- 組織管理者（カスタマーポータルを通じて付与される役割）は、組織内の任意のメンバーによってプロビジョニングされたすべてのクラスタを表示および管理できます。

ちゃんと理解して設定しないといけないことがわかった

正直、Support Case上げるときしか使わないと思っていたRed Hat Accountですが、ROSAをしっかり乗りこなすには、このあたりの仕組みを理解して、整備しないといけないことがわかりました。今回はただ単に子アカウントを作って、デフォルトのRBACで効いているコントロールの一部を確認したに過ぎず、真面目に使うにはRoleやGroupの設計も要る気がします。

以下が学習用のコンテンツです。頑張って読みます。

Chapter 5. Configuring access to clusters in OpenShift Cluster Manager
User Access Configuration Guide for Role-based Access Control (RBAC)

それでは、良いお年を〜🍶