はじめに

AWSでいう「アカウント」、Google Cloudでいう「プロジェクト」に近い概念がOCIにもあり、それがOracle Cloud Infrastructureでいう「テナンシー」です。
参考：https://docs.oracle.com/ja-jp/iaas/Content/GSG/Concepts/concepts-account.htm

今回は、テナンシーAからテナンシーBへアクセスし、テナンシーBのリソース情報を取得したく、テナンシー間アクセス（クロステナンシー）をやってみたので方法や注意点をまとめました。

前提知識

  • テナンシー： 「AWSのアカウント」や「Google Cloudのプロジェクト」に近い概念。
  • コンパートメント： テナンシーの中を分離する仕組み。階層化できる箱のようなもの。
  • ルートコンパートメント： テナンシーそのものを指す。テナンシーが作成されると、自動的に同名のルートコンパートメントが作成される。ルートコンパートメントは、テナンシー内に作成される他のすべてのコンパートメント（サブコンパートメント）の親となる。

参考：https://docs.oracle.com/ja-jp/iaas/Content/GSG/Concepts/settinguptenancy.htm#Understa

前提条件

  • テナンシー間アクセスは「アイデンティティとセキュリティ」にてポリシーの設定を行いアクセスを制御します。
  • この際、「Admin」ポリシーの設定が必要でした。「Admin」ポリシーの作成はルートコンパートメントで行うため作業者にルートコンパートメントへのアクセス権限の付与が必要でした。

ポリシー設定

※ポリシーはルートコンパートメント（テナンシー直下）に作成します。

設定の全体イメージ図

テナンシーA（アクセス元/リクエスト元）で作成するポリシー

  • テナンシーBへアクセスすることを承認（Endorse）するためのポリシー
Define tenancy DestinationTenancy as <テナンシーBのOCID>
Endorse group <テナンシーAのアクセスを行うグループ名> to <許可する操作> in tenancy DestinationTenancy

テナンシーB（アクセス先/リソース保有）で作成するポリシー

  • テナンシーAからのアクセスを許可（Admit）するためのポリシー
Define tenancy SourceTenancy as <テナンシーAのOCID>
Define group GroupFromSource as <テナンシーA内の、アクセスするグループのOCID>
Admit group GroupFromSource of tenancy SourceTenancy to <許可する操作> in compartment <テナンシーBに存在する、リソースを取得したいコンパートメントのOCID>

※ in compartment <テナンシーBに存在する、リソースを取得したいコンパートメントのOCID> は in tenancy とすることで、テナンシーB全体の読み取りを許可できます。

参考：https://docs.oracle.com/en-us/iaas/Content/Identity/policieshow/iam-cross-domain.htm

アクセスできるかの確認

ブラウザでテナンシーAのOCIコンソールから確認できます。

  1. OCIコンソール右上のDeveloper tools > Cloud Shell を開く
  2. コマンド実行例（Block volume一覧を取得する場合） oci bv volume list --compartment-id テナンシーBのコンパートメントID --region リージョン ※–compartment-id では取得対象のリソースが存在する直下のcompartment-idを指定する必要がありました。

まとめ

OCIにおけるクロステナンシーアクセスは、異なるテナンシー間でリソースを安全に共有するための仕組みです。
アクセス元のテナンシーでアクセスを「承認（Endorse）」し、アクセス先のテナンシーでアクセスを「許可（Admit）」する、という双方向の設定が必要になります。
注意すべきは、この設定にはルートコンパートメントでのポリシー作成が必要であり、そのための適切な権限をつけることです。

クロステナンシーアクセスは、複数のプロジェクトや部署でリソースを共有する際に不可欠な仕組みであり、本記事で紹介したポリシー設定の基本を押さえ、セキュリティを考慮しながら活用していきましょう。