はじめに
こちらの記事は下記Advent Calendar 2024で紹介しているIBM Cloud権限設定における 権限共通部分 になります。
IBM Cloudの権限の大枠
IBM CloudのIAMで定義できる権限には大きく２種類あります。
- プラットフォーム・アクセス
- サービス・アクセス
それぞれ何が違うのかでしょうか？
プラットフォーム・アクセス
プラットフォーム・アクセスは、そのIBM Cloudアカウントの中にサービス自体を作成、編集、削除する権限を指します。
わかりやすいか難しいですが、IBM Cloudのリソースリストに出てくるようなサービスのインスタンスを操作する権限になります。
つまりサービスそのものを作る権限が含まれるので、あらゆるサービスに対して プラットフォーム・アクセス の権限は必ずあります。
サービス・アクセス
一方、 サービス・アクセス は、出来上がったサービスインスタンスが持つ サービス に対する権限になります。
わかりやすいのがObject Storageで、プラットフォーム・アクセスの権限でサービスインスタンスを作成することは可能ですが、Object Storageの中に実際にファイルを格納するためのBucketを作成する権限や、そのBucketの中にファイルを配置する権限は サービス・アクセスに分類されます。
なので、IBM Cloudの権限設定できる対象の一部には、プラットフォーム・アクセスの権限設定はあるけれど、サービス・アクセスの権限設定は無い、というものがあります。
一例ですが、請求情報を確認可能な Billing、サポートへの問い合わせができる Support Centerといった権限は、プラットフォーム・アクセスの権限設定はありますが、サービス・アクセスの権限設定が無いものになります。
共通する権限の役割(Role)
プラットフォーム・アクセス、サービス・アクセスのそれぞれにはIBM Cloud側が標準で設定している 役割(Role) があります。カスタムロールを作成して、アカウントオリジナルな役割を作成することもできますが、ここでは説明を割愛し、標準の役割について紹介します。
プラットフォーム・アクセスの役割(Role)
プラットフォーム・アクセスには6つの役割が標準で設定されています。
- Viewer : サービスインスタンスを表示できますが、変更は一切できません
- Operator : サービスのダッシュボードの表示して構成要素の変更は可能ですが、サービスの新規作成や削除ができません
- Editor : アクセス・ポリシー(該当サービスのアカウント内での権限設定)はできませんが、サービスの新規作成や削除も含めてそれ以外の操作は可能です
- Administrator : 管理者権限で全ての操作が原則可能です
- Key Manager : サービスのリソース・キーの管理が行えます
- Service Configuration Reader : サービスの構成のみ参照可能です
Key Managerについては執筆時点で利用するケースが想像できない状況で、サービスの資格関連情報が見えるわけではなかったです。内容確認できてから、また記事を更新します。
サービス・アクセスの役割(Role)
サービス・アクセスには3つの役割が標準で設定されています。
- Reader : サービス内での読取専用相当の権限
- Writer : サービス内での更新権限
- Manager : Writerを超える管理者権限
標準で設定された役割に振られている権限の詳細
先ほどは各Roleでどういった趣旨の権限になるか説明しましたが、具体的にどんな権限が設定されているか見てみましょう
プラットフォーム・アクセスの役割別権限
※Admin : Administrator, KM : Key Manager, SCR : Service Configuration Reader
サービスインスタンスに対する権限
| 権限 | Viewer | Operator | Editor | Admin | KM | SCR |
|---|---|---|---|---|---|---|
| resource-controller.instance.retrieve | 〇 | 〇 | 〇 | 〇 | 〇 | |
| resource-controller.instance.retrieve_history | 〇 | |||||
| resource-controller.instance.update | 〇 | 〇 | 〇 | |||
| resource-controller.instance.update_plan | 〇 | 〇 | ||||
| resource-controller.instance.create | 〇 | 〇 | ||||
| resource-controller.instance.delete | 〇 | 〇 |
これがIBM Cloud利用者にとって一番大事な権限ですね。対象のサービスを作成しようとした場合に必要な権限は何か、設定だけ変更した場合の権限が何かといったものです。
新規作成するにはEditor、Administratorの権限が必要ですが、作成済のサービスに対する変更はOepratorでも実施できるものが出てきます。これはサービス如何によって変わってくるところですね。
サービスインスタンス表示における権限
| 権限 | Viewer | Operator | Editor | Admin | KM | SCR |
|---|---|---|---|---|---|---|
| global-search-tagging.resource.read | 〇 | 〇 | 〇 | 〇 | 〇 | |
| global-search-tagging.tag.attach-user-tag | 〇 | 〇 | ||||
| global-search-tagging.tag.detach-user-tag | 〇 | 〇 | ||||
| global-search-tagging.tag.attach-access-tag | 〇 | |||||
| global-search-tagging.tag.detach-access-tag | 〇 |
タグが付与されているかに関わらずリソース一覧ではそのリソースのタグが確認できるので、Key Managerを除いて全ての権限でタグが付いたリソースの参照権限が付与されます。これによりタグでのリソース検索も可能です。
一方、Editor、Administratorの権限が無いとこのリソース一覧で表示されるタグを付与したり削除することはできません。
アクセス管理タグは添付のようにアクセス権限の設定時に利用可能な特別なタグを付与することができます。
先の説明でEditorにはアクセスポリシーといった権限設定を行うための権限が無いため、このアクセス管理タグの作成、削除は権限がなく、Administratorしか実施できないものになっています。
リソース・グループ関連の権限
| 権限 | Viewer | Operator | Editor | Admin | KM | SCR |
|---|---|---|---|---|---|---|
| resource-controller.group.retrieve | 〇 | 〇 | 〇 | 〇 | ||
| resource-controller.group.update | 〇 | 〇 | 〇 | |||
| resource-controller.group.create | 〇 | 〇 | ||||
| resource-controller.group.delete | 〇 | 〇 |
所感としてはこの権限はリソース・グループのみの部分だけで使っているのかな、というものです。
現在、下記のように リソース・グループのみという権限設定があり、この権限でリソース・グループに対する参照権限や新規リソース・グループの作成といった権限が付与可能になっています。共通部分にこの権限が出てきますが、他の権限部分で使っているのかよくわからない、といったところです。
アクセスポリシー関連の権限
| 権限 | Viewer | Operator | Editor | Admin | KM | SCR |
|---|---|---|---|---|---|---|
| iam.policy.read | 〇 | 〇 | 〇 | 〇 | ||
| iam.policy.create | 〇 | |||||
| iam.policy.delete | 〇 | |||||
| iam.policy.update | 〇 | |||||
| iam.delegationPolicy.create | 〇 | |||||
| iam.delegationPolicy.update | 〇 | |||||
| iam.role.read | 〇 | 〇 | ||||
| iam.role.assign | 〇 |
アクセス・ポリシーに順守しているか、自身に付与された権限が何かを確認できるように iam.policy.readは設定されます。
ポリシー自体の作成はAdministratorにしかできないので、期待通りの設定です。
iam.delegationPolicyは別のサービスへのアクセス権限の設定になります。例えば、Activity Tracker Event RoutingとCloud Logsを連携する場合や、Security and Compliance CenterでレポートをICOSに保存する時といったように、サービス間で連携するケースがあります。この場合にAdministrator権限が必要になります。
iam.role.readにViewerだけ〇がついてるのは何かの間違いのような・・・
Context-base Restrictionの権限
| 権限 | Viewer | Operator | Editor | Admin | KM | SCR |
|---|---|---|---|---|---|---|
| cbr.rule.read | 〇 | 〇 | 〇 | 〇 | ||
| cbr.rule.create | 〇 | |||||
| cbr.rule.delete | 〇 | |||||
| cbr.rule.update | 〇 |
権限を設定するサービスがContext-base Restrictionに対応しているかに関係なく上記の権限がセットされます。サービスインスタンスにアクセスするユーザーは自身がContext-base Restrictionで設定された制約を満たしているか確認するため、プラットフォーム・アクセスが何かしら設定されると必ず参照権限が付与されます。
一方、サービスに対してContext-base Restrictionを利用してアクセス元に対する制限を設定できるのはAdministratorのみとなっています。
認証情報に対する権限
| 権限 | Viewer | Operator | Editor | Admin | KM | SCR |
|---|---|---|---|---|---|---|
| resource-controller.key.retrieve | 〇 | 〇 | 〇 | 〇 | ||
| resource-controller.key.update | 〇 | 〇 | 〇 | |||
| resource-controller.key.create | 〇 | 〇 | 〇 | |||
| resource-controller.key.delete | 〇 | 〇 | 〇 | |||
| resource-controller.credential.retrieve_all | 〇 | |||||
| resource-controller.key.manager_create | 〇 | |||||
| resource-controller.key.manager_delete | 〇 | |||||
| resource-controller.key.manager_retrieve | 〇 | |||||
| resource-controller.key.manager_update | 〇 |
サービスに作成された認証情報(アクセスキー等)はプラットフォーム・アクセスのViewer権限があればその一覧を確認することは原則としては可能です。(サービス・アクセスのReader以上の権限が必要な場合もあります)
ただ、その具体的な認証情報の中身はViewerでは確認することはできず、またOperator以上の権限では基本的にそのユーザーで作成した認証情報のみ確認が可能で、他のユーザーが作成した認証情報は見えない形になります。
Administratorの権限では、 resource-controller.credential.retrieve_allの権限があるため、サービスで作成された認証情報の全てにアクセスすることが可能です。
申し訳ないのですが、resource-controller.key.manager_*の権限がどこで利用されるかは謎のままとなっています。
- Key Manager権限だけ付与しても特にそのサービスで認証情報の作成はできない
- 同様に既存の認証情報の更新や削除もできない
- Key Protect等鍵管理用のサービスと紐づけた場合にKey Protect側で鍵のローテートをする場合に鍵に紐づくサービスのKey Manager権限が必要かとおもいきや、そういうわけでもない
- おまえはいったい何に使われる権限なんだ…
Quotaの確認権限
| 権限 | Viewer | Operator | Editor | Admin | KM | SCR |
|---|---|---|---|---|---|---|
| resource-controller.quota.retrieve | 〇 | 〇 | 〇 | 〇 |
サービスには利用の上限が定められたものがあります。そういった上限(Quota)の確認権限はViewer以上の権限があれば確認できるようです。
エイリアスとバインディング関連の権限(廃止済)
| 権限 | Viewer | Operator | Editor | Admin | KM | SCR |
|---|---|---|---|---|---|---|
| resource-controller.alias.retrieve | 〇 | 〇 | 〇 | 〇 | ||
| resource-controller.alias.update | 〇 | 〇 | 〇 | |||
| resource-controller.alias.create | 〇 | 〇 | 〇 | |||
| resource-controller.alias.delete | 〇 | 〇 | 〇 | |||
| resource-controller.binding.retrieve | 〇 | 〇 | 〇 | 〇 | ||
| resource-controller.binding.update | 〇 | 〇 | 〇 | |||
| resource-controller.binding.create | 〇 | 〇 | 〇 | |||
| resource-controller.binding.delete | 〇 | 〇 | 〇 |
こちらの権限は権限設定の画面では含まれている権限の一覧に記載がされているのですが、エイリアスとバインディングはサービス終了となったCloud Foundryのサービスで使われていた権限のため、権限としては廃止されている状況です。
例えばCode Engineでは既存リソースと接続して利用することが可能なのですが、こちらの権限は利用せず異なる方法で実現しています。
下記のAPI一覧でもBindingとAliasについてはグレーアウトしています。
https://cloud.ibm.com/apidocs/resource-controller/resource-controller#list-resource-bindings
Broker関連の権限
| 権限 | Viewer | Operator | Editor | Admin | KM | SCR |
|---|---|---|---|---|---|---|
| resource-controller.broker.retrieve | 〇 | 〇 | 〇 | 〇 | ||
| resource-controller.broker.update | 〇 | 〇 | 〇 | |||
| resource-controller.broker.create | 〇 | 〇 | ||||
| resource-controller.broker.delete | 〇 | 〇 |
こちらの権限はIBM Cloud上のService Brokerを利用する場合の権限なので、IBM Cloud上にサービスを提供する、といったケース以外では利用しないかと思います。
サービス・アクセスの役割別権限
| 権限 | Reader | Writer | Manager |
|---|---|---|---|
| cbr.rule.read | 〇 | 〇 | 〇 |
| global-search-tagging.resource.read | 〇 | 〇 | 〇 |
| iam.policy.read | 〇 | 〇 | 〇 |
サービス・アクセスで共通して出現する権限は上記の3つになります。
既にプラットフォーム・アクセスの権限で出てきている権限ですが、、、
- Context Base Restrictionを参照する
- タグの付いたリソースを参照できる
- 権限ポリシーを参照できる
つまり、サービスにアクセスする際に自身に必要な権限があるか(Context-base Restrictionで指定された制約を満たしているか)を確認するために必要な権限が共通化されており、あとは各サービス毎にオリジナルな権限設定となってます。
さいごに
以上で、共通部分の権限の紹介を終わりにします。
正直なところ、どこで使っているのかよくわからないものも多く、Document見ても書いていないといったものも見受けられたので、最終的には個々のサービス毎に設定されている権限をちゃんと確認してね、ということかと思いました。
今後特定のサービスの権限について紹介する際は、こちらの共通部分として定義されている権限を省いて紹介するので、これらの権限があるんだなーというのはなんとなく理解してもらえたら幸いです。