概要
本記事では、OCI IAM リソースにおける主要コンポーネントに関する概要と関係をまとめていきます。
ただまとめるだけではなく、普段 AWS をメインに扱っている身として、AWS IAM リソースの各コンポーネントとの関連付けをしながらまとめていきます。
同じ境遇の方は是非参考にしてみてください。
- 完全一致ではない点ご了承ください。。。
IAM 全体像
今回整理する IAM リソースの全体像を以下図に示します。
- 本記事で整理するコンポーネントのみ記載しているため、これが全てではないことご了承ください
各コンポーネント
テナンシ
一言で言うと アカウント のことです。
AWS アカウントと同じ立ち位置 です。
世界中にある OCI のデータセンター群を論理的な管理領域として区分けしたものになります。
コンパートメント
テナンシで定義するリソースをグループ化するための論理的なコンポーネント です。
OCI 独自のものです。
コンパートメントはリージョンをまたがるため、AWS で言うところのグローバルリソース に当てはまります。
特徴1 - 階層化できる
コンパートメントは階層化することができます。
テナンシを開設すると、必ず ルートコンパートメントが 1 つ作成されています。
このルートコンパートメントを起点に 最大 6 階層までネスト可能 です。
AWS でイメージすると、AWS Organizations の OU に近い ですね。
特徴2 - 権限分離できる
前提として、テナンシに作成するリソースは 必ず 1 つのコンパートメントに所属させる必要があります。
そして後述しますが、認可を担うポリシーは テナンシ or コンパートメントに紐づけます。
加えて、紐づけたポリシーは継承されます。
つまり、コンパートメントの分け方とポリシーの紐づけ方の組み合わせにより、認証主体(Principal)に対する権限分離が可能となります。
- コンパートメントが異なるリソース間のOSレベルのアクセスは可能です
- ただし、リソースが主体となり OCI API を使って別コンパートメントのリソースを操作する場合は、後述するポリシーによる権限が必要です
- AWS でも AWS API を使った操作には IAM ポリシーやリソースベースポリシーで権限を付与する必要があるのと同じ考えです
特徴3 - コスト明確化が容易
OCI コンソールにて、テナンシで発生したコスト を確認することが可能ですが、その際 コンパートメント毎に確認することが可能 です。
また、ただ確認できるだけでなく コンパートメント毎に予算アラートを設定することが可能 です。
AWS でイメージすると、AWS Organizations の管理アカウント側の Cost Explorer で、メンバーアカウント毎に確認できるのと近い ですね。
注意点としては、支払先を分けることはできません。
分けたい場合は、テナンシを分けて個々で管理するか、テナンシを分けた上で OCI Organization Management で管理する必要があります。
アイデンティティ・ドメイン
後述する ユーザー/グループ(ユーザーグループ、動的グループ)や関連するセキュリティ設定等を管理するコンテナ です。
簡潔に示すと、OCI の認証を一元管理するもの です。
ユーザーは OCI コンソールへログインする際に、ユーザー情報が格納されているアイデンティティ・ドメインを指定するのですが、その認証イメージ図を ORACLE社のスライドから抜粋して記載します。
アイデンティティ・ドメインにはドメインURLがあり、ユーザーがログインする際はこのドメインURLにリダイレクトされています。つまり、認可エンドポイントということになります。
以上のことから、AWS でイメージすると、AWS IAM Identity Center のインスタンスに近い ですね。
デフォルト・アイデンティティ・ドメイン
テナンシを開設した際、ルートコンパートメントに自動で作成されるアイデンティティ・ドメイン の呼び名です。
このドメインで管理されているリソースは、サブスクライブしたリージョンに自動的にレプリケートされます。
また自動的に Administrators グループと All Domain Users グループが作成されており、テナンシ開設時のユーザーが Administrators グループに所属しています。これらのグループは削除不可であり、Administrators グループには少なくとも 1 人所属させる必要があります。
All Domain Users は、どのアイデンティティ・ドメインに所属する全てのユーザーがデフォルトで所属するグループです。
All-Domain-Usersグループは、IAMによって作成されるグループです。デフォルトでは、すべてのアイデンティティ・ドメイン・ユーザーがこのグループに割り当てられます。このグループを任意のアプリケーションに割り当てると、すべてのユーザーがこれらのアプリケーションに間接的に割り当てられます。
ユーザーに対し、All-Domain-Usersグループは「グループ」タブに表示されません。このグループは、新規ユーザーの作成時に自動的に割り当てられるためです。また、このグループは、管理者ではなくIAMによって作成されるため、削除できません。
そして、Tenant Admin Policy という名前のポリシーが作成されており、Administrators グループに対して、テナンシ内の全てのリソースへのフルアクセスが定義されています。
つまり、Administrators グループに所属するユーザーは、AWS で言うところの root ユーザーとなります。
Administrators グループに別途ユーザーを追加することは非推奨 となります。
アイデンティティ・ドメインは複数作成可能
アイデンティティ・ドメインは追加で作成することが可能です。
追加作成したアイデンティティ・ドメインで管理する IAM リソースは、デフォルト・アイデンティティ・ドメインと異なり、サブスクライブしたリージョンに自動レプリケーションされないため、明示的にレプリケーションを有効化する必要があります。
選べるタイプ
アイデンティティ・ドメインには 4 種類のタイプがあります。
タイプにより機能が異なり、有料のタイプもあります。
基本的には Free タイプで十分ですが、より細かな制御を実施したい場合は上位タイプの利用を検討する必要があります。デフォルト・アイデンティティ・ドメインは Free タイプです。
各タイプの違いについては以下試料を参照してみてください。
管理者ロール
前提として、ユーザーへ権限を付与するには、後述するポリシーにて、ユーザーが所属するグループはどういったことができるかを記述する必要があります。
そう言ったポリシーを記述する手間を省けるのが管理者ロールです。
管理者ロールは、特定の権限を持つ定義済みロールと表現されますが、つまりは OCI 側で良しなに定義された権限が付与されたグループみたいなもの です。
種類は割愛しますが、幾つか定義されており、各ロールにユーザーを追加することで、そのユーザーに特定の権限を付与することが可能です。
ドメインポリシー
アイデンティティ・ドメインに所属するユーザーに対して課すログイン関連のポリシーです。
現状は「サインオン・ポリシー」と「パスワード・ポリシー」のみ存在しています。
以下図は、デフォルト・アイデンティティ・ドメインにてテナンシ開設時にデフォルトで適用されているものです。
サインオン・ポリシーに関しては、AWS だと IAM ポリシーで MFA を強制させたりしていますが、OCI だと直感的に設定できますね。
パスワード・ポリシーに関しては、AWS だとアカウント全体で一つの設定ですが、OCI だとアイデンティティ・ドメイン単位なので柔軟に対応ができそうですね。
ユーザー/グループ
ユーザーはその名の通り、OCI を操作する個人です。
AWS で言うところの IAM ユーザー に当てはまります。
グループはユーザーの集合体です。
AWS で言うところの IAM グループ に当てはまります。
動的グループ
上述したユーザーをまとめるグループとは違い、OCI で作成したリソースをまとめるグループ です。
リソースをグループ化する理由は、後述するポリシーによって、OCI リソース自身が CRUD 操作(OCI API操作)を可能にするため です。
(ユーザー・グループと同様に)コンピュート・インスタンスおよびその他のリソースをプリンシパルのアクターとしてグループ化できます。次に、ポリシーを作成して、リソースによるサービスに対するAPIコールの実行を許可できます。
AWS で言うところの IAM ロール に当てはまります。
動的グループではフィルター条件でグループ化します。
AWS IAM ロールで言うところの信頼ポリシーと近いですね。
ポリシー
前提として、OCI のリソースへの CRUD 操作(OCI API操作)には権限が必要です。
そして、その権限は CRUD操作を実行する主体(Principal)である「誰に」付与するかを決める必要があります。
いわゆる「認可」です。
この認可を決めるものがポリシーです。
AWS で言うところの IAM ポリシー に当てはまります。
OCI のポリシーは、許可のみを定義するホワイトリスト方式 です。
AWS だと拒否も定義できますが、OCI は許可のみです。
ポリシーは、テナンシ or コンパートメントに紐づけます。つまり、実行主体とテナンシ or コンパートメントに関連付けるイメージです。
そしてそのポリシーは継承されます。つまり、テナンシに紐づければ全てのコンパートメントに継承され、特定のコンパートメントに紐づければ下位層に継承されます。
構文は以下の通りです。
色付き箇所が可変になります。詳細は以下リファレンスを参考にしてみてください。
Allow <subject> to <verb> <resource-type> in <location> where <conditions>
上記構文の可変部分に関して、AWS の記述とのマッピングをしてみます。
まず、subject と location についてみていきます。
subject は「誰に」を記述するところで、具体的には「どのグループか」もしくは「どの動的グループか」を指定します。
location は「どこに」を記述するところで、具体的には「テナンシ(ルートコンパートメント)」もしくは「コンパートメント」を指定します。
AWS IAM ポリシーでは、実行主体は明示的であることから「誰に」を記述しません。加えて「どこに」は構文としてありません。
そのため、AWS IAM ポリシーの構文にマッピングはできません。ただ視点を変えて、AWS IAM ポリシーには「このポリシーをどの IAM ロール or IAM グループ or IAM ユーザーに紐づけるか」を意味するアタッチメントという、マネジメントコンソール操作だと意識しないコンポーネントがあります。
ちょっと無理くりですが、subject と location の組み合わせが、アタッチメントに該当するのではと考えています。
- リソースベースポリシー(バケットポリシー等)では「誰に(Principal)」を記述しますが対象外とします
- ポリシー構文には明記されていないのですが、
subjectにはgroup及びdynamic-group以外にserviceが指定できます -
serviceはその名の通り OCI サービスです (Object Storage等) - 使い分けはまだよくわかっていないですが、AWS で例えると IAM ロールが必要なサービス ( EC2 や Lambda )に該当する OCI Compute や OCI Functions は
dynamic-groupを、IAM ロールが紐づけられないサービス ( S3 や EventBridge ) に該当する OCI Object Storage や OCI Events はserviceを使うと現時点では理解しています
続いて、verb についてみていきます。
verb は「どういった権限を」を記述するところです。
AWS IAM ポリシーで言うところの Action に該当します。
続いて、resource-type についてみていきます。
resource-type は「どの OCI リソース(サービス)の」を記述するところです。
AWS IAM ポリシーで言うところの Resource に該当します。
最後に、conditions についてみていきます。
conditions は「どういう条件の」を記述するところです。
AWS IAM ポリシーで言うところの Condition に該当します。
ポリシーの所属先コンパートメントに注意
「テナンシに作成するリソースは必ず 1 つのコンパートメントに所属させる必要がある」というのはポリシーも例外ではありません。そのため作成する際は、どのコンパートメントに所属させるかを決めます。
ここで改めてポリシー構文を以下に示します。
location に指定可能な条件は以下の通りです。
- 該当ポリシーが所属するコンパートメント
- 該当ポリシーが所属するコンパートメントの下位層のコンパートメント
つまり、該当ポリシーが所属するコンパートメントと同階層 もしくは 上位層のコンパートメントは指定できません。
そのため、ポリシーを所属させるコンパートメントは気を付ける必要があります。
加えて、ポリシーを所属させるコンパートメントは後から変更不可 なので気を付ける必要があります。
Allow <subject> to <verb> <resource-type> in <location> where <conditions>
-
locationは「どのテナンシ(ルートコンパートメント) or どのコンパートメント に紐づけるか」を意味しています - 「ポリシーをどのテナンシ(ルートコンパートメント) or どのコンパートメント に所属させるか」ではないので注意してください
-
subjectにグループ名もしくは動的グループ名のみを記載した場合、暗黙的にDefaultドメインのものとみなされますので注意してください - これはどのコンパートメントにポリシーを配置したとしても変わりません
- そのため基本的にはアイデンティティ・ドメイン名も明記するようにした方が良いです
＜例＞
Allow Group test to manage all-resources in compartment A
↓
Allow Group 'Default'/'test' to manage all-resources in compartment A
ネットワーク・リソース
IP アドレス/CIDR のリスト です。
ネットワーク・リソースの使い所は、上述したポリシーの conditions です。
そうすることで、権限を実行する主体の送信元 IP 制限が可能となります。
AWS でイメージすると、PrefixLists に近い ですね。
ただし、AWS の場合は通信制御に使用しますが、OCI では権限制御に使用するので役割は異なりますね。
なのでもう少し近いイメージだと、AWS IAM ポリシーの Condition に記述する SourceIp を外だししたのがより近いかもしれません。
個人的なまとめ
各コンポーネントをまとめてきましたが、個人的にそれぞれ AWS で例えると以下のようなイメージに落ち着いています。
- 厳密には違いますが。。。あくまでイメージです。。。
| OCI | AWS |
|---|---|
| テナンシ | アカウント |
| コンパートメント | AWS Organizations OU |
| アイデンティティ・ドメイン | AWS IAM Identity Center インスタンス |
| 管理ロール | AWS 管理ポリシー (AdministratorAccess等) |
| ユーザー/グループ | AWS IAM Identity Center で管理するユーザー/グループ |
| 動的グループ | IAM ロール (信頼ポリシーの Principal が Service) |
| ポリシー | IAM ポリシー + SCP |
| ネットワーク・リソース | PrefixLists |
おわりに
本記事では、OCI IAM リソースにおける主要コンポーネントついて、AWS IAM リソースの各コンポーネントとの関連付けをしながらまとめました。
認証認可を司るサービスですのでまだまだ多種多様な機能がありますが、まずは本記事で取り上げた概念を理解していただけたらなと思います。
🌟この記事が誰かの役に立てば幸いです！
また、ご質問やフィードバックもお待ちしています。
番外編
OCI IAM ってリージョンサービスなのか
AWS を扱っている身からすると、OCI コンソールではグローバルがないしホームリージョンって概念があるので、OCI IAM ってリージョンサービスなのかと初めは思いました。
ただ、そうではなくグローバルサービスである と考えています。
前提として、OCI はテナント開設時にホームリージョン(いわゆる主とするリージョン)を選択し、他リージョンは適宜サブスクライブして使っていきます。
アイデンティティ・ドメインで管理しているリソース(ユーザー/グループ等)やポリシーなどの IAM リソースはホームリージョンで定義されます。
ホーム・リージョンは、IAMリソースが定義される場所です。別のリージョンにサブスクライブすると、IAMリソースは新しいリージョンで使用可能になります。ただし、定義はホーム・リージョンに配置され、そこでのみ変更できます。
ホーム・リージョンでのみ作成および更新可能なリソースは、次のとおりです。
● ユーザー
● グループ
● ポリシー
● コンパートメント
● 動的グループ
● フェデレーション・リソース
上記の説明だけ読むと、AWS を扱っている身からすると リージョンサービスなのかなと考えてしまうのですが、それは違うと思っています。
ここで一旦 AWS IAM の話をします。
AWS ではコントロールプレーン(管理API)とデータプレーン(各サービス機能API)という概念があります。
この概念を AWS IAM に落とし込むと、コントロールプレーンは us-east-1 にあり、データプレーンは各リージョンに伝搬しています。
IAM サービスのコントロールプレーンは us-east-1 リージョン内にあり、データプレーンはパーティション内の各リージョンに分離されています。
OCI に戻します。
上記の理解に加え、以下の内容も含めると、仕組みは AWS と同じで、あくまでコントロールプレーンのリージョンをホームリージョンと呼んでいるだけだと理解しています。
以上のことから、OCI IAM はグローバルサービスであると理解しています。
APIを使用してIAMリソースを更新する場合、ホーム・リージョンのエンドポイントを使用する必要があります。(テナンシのホーム・リージョンとは何ですか。テナンシのホーム・リージョンはどのように検索しますか。を参照) IAMによって更新内容がテナンシ内のすべてのリージョンに自動的に伝播されます。
コンソールを使用してIAMリソースを更新すると、コンソールからホーム・リージョンにリクエストが送信されます。最初にホーム・リージョンに切り替える必要はありません。次にIAMは、テナンシ内のすべてのリージョンに更新を自動的に伝播します。
参考資料
リファレンス
- Oracle Cloud Infrastructure ドキュメント - Oracle Help Center
- コントロールプレーンとデータプレーン - AWS 障害分離境界 AWS ホワイトペーパー
- グローバルサービス - AWS 障害分離境界 AWS ホワイトペーパー