はじめに

Azure AD と Oracle Cloud Infrastructure Console (以降 OCI と呼称) を SAML 連携し Azure AD ユーザーを使い OCI にシングル サインオンができる環境において、OCI 側で構成した Identity and Access Management (以降 IAM と呼称) が Azure AD に対してどのような形で割り当たって動作するかについて検証を行いました。

本検証にあたり Azure AD と OCI を SAML 連携する必要がありますが、こちらの手順については以下記事にまとめていますので今回の記事では SAML 連携の手順は割愛します。

-参考情報
Oracle Cloud Infrastructure Console と Azure AD を SAML 連携しシングル サインオンを構成するために必要な一連の手順
URL:https://qiita.com/Shinya-Yamaguchi/items/729bb70f8a10332f31de

まず、今回の検証で出てくる登場人物は以下のとおりです。
これらの登場実物の関係性を順番に説明していきます。

Azure AD と OCI を SAML 連携する過程で、グループ マッピングの設定画面で Azure AD 側のグループと OCI グループをマッピングする必要があります。
設定は OCI のコンソール画面で行い、 Azure AD 側のグループ (グループのオブジェクト ID) と OCI 側のグループをマッピングさせます。
イメージとしては以下のような感じになります。
必ず 1 対 1 でマッピングさせます。

Azure AD ユーザーは Azure AD 上のグループに所属していないと OCI 側の権限を使えないので必ずいずれかのグループに所属させます。
また、OCI 側ではグループとは別に独立してポリシーという概念が存在します。

このポリシーの中でどのグループに対して設定した権限を付与するかを定義しますが、付与する対象は 1 つのグループでも良いですし、複数、極端な話、すべてのグループとして定義することもできます。

今回検証で確認したい内容は、以下図のように 1 つのユーザーが複数のグループにまたがって所属している場合、マッピングされたグループに定義された権限が片方のグループの権限しか使えないのか、それとも所属している両方のグループの権限が使えるかについて確認を行いました。

やってみる

まず、今回の検証環境における OCI 側のグループマッピングは以下のように構成されています。

アイデンティティ・プロバイダ・グループ列が Azure AD 側のグループのオブジェクト ID になります。

次に、OCI 側のグループの一覧は以下のように構成されています。
Administrators というのはデフォルトで作成される Oracle Cloud 上のすべてのリソースを操作できるポリシーが割り当てられたグループになります。
この中で試しに、「Compute-Operation-Group」のリンクをクリックします。

グループ メンバーに何もユーザーがいないのは、想定された動作です。
今回は Azure AD 側のユーザーを使ってシングル サインオンをするのと、OCI は JIT プロビジョニングに対応しているので、OCI 側にユーザーを用意する必要がないためです。

ここにユーザーが表示されるケースは、OCI 側でローカルのユーザーを作成するか、Azure AD からユーザーをプロビジョニングする構成をして、OCI 側にユーザーを同期させた場合になります。

今回注目して欲しい点はこのグループの画面にどのようなポリシー、つまり、権限が付与されているかグループの画面内では確認ができない、という点です。
Azure を利用したことがある方はイメージしやすいと思いますが、Azure の場合は RBAC というロール ベースのアクセス制御方法があり、ユーザー、グループ、サービス プリンシパルなどの単位でロール (権限) を付与して、それぞれの単位でどのロールが割り当たっているのかを確認できますが、OCI の場合はポリシーという単位で権限を割り当て、確認する必要があります。

この辺りはクラウド サービスによりお作法が異なるのでそれぞれ違う管理方法があるんだ、というくらいでとどめたいと思います。
IAM という大きな括りで見ると、そこまで大きな違いではないかなと思います。

OCI のポリシーは OCI コンソール画面のグループと同じ「アイデンティティ」の欄にあります。

こちらがポリシーの一覧になります。

既定では、「Tenant Admin Policy」と「PSM-root-policy」の 2 つのポリシーしかありません。
例として手動で作成した「instance-family」をクリックします。

こちらが手動で作成したポリシーの中身になります。
ここで大事なのが ステートメントの項目になります。

ポリシーを作成する際に必ずステートメントを最低でも 1 つ定義する必要がありますが、ここでどのグループに権限を付与するかどうかを記述しています。

このステートメントを書く時の構文は明確に定義されています。

-参考情報
ポリシー構文
URL:https://docs.cloud.oracle.com/ja-jp/iaas/Content/Identity/Concepts/policysyntax.htm

構文、つまり、ステートメントの書き方は以下になります。

Allow <subject> to <verb> <resource-type> in <location> where <conditions>

ポリシー名「instance-family」を例に見てみましょう。

Allow group Compute-Operation-Group to manage instance-family in tenancy

このステートメントの意味は、グループ名「Compute-Operation-Group」を対象に、リソースタイプ「instance-family」に対してすべてのオペレーションが行える「manage」を与えています。

ここでは詳細は割愛しますが、上記の については、以下 Oracle 社の公開情報に細かく記載されていますのでご確認ください。

-参考情報
ポリシー参照
URL:https://docs.cloud.oracle.com/ja-jp/iaas/Content/Identity/Reference/policyreference.htm#Resource

前置きが長くなりましたが、test008 ユーザーから OCI にシングルサインオンして権限付与の動作がどうなるか確認していきましょう。

test008 ユーザーの動作

test008 ユーザーに関するマッピングは以下になります。

Azure AD のアクセス パネル (myapps.microsoft.com) に test008 ユーザーでサインインしたのが以下画面ショットです。
ここに表示されている OCI のアイコンをクリックします。

シングル サインオンの欄にある Continue をクリックします。

OCI コンソール画面にシングル サインオンできました。
コンソール画面の左ペインにある、「コンピュート」→「インスタンス」の順にクリックしてみます。

下記画面ショットのようにインスタンスの「リソースを表示する権限がない」と表示されていることが分かります。
これは、「test008」に所属しているグループ名「Group001」とマッピングされている OCI グループ名「non-policy-group001」には、何もポリシーが割り当てられていない、つまり、閲覧も含む何も権限がないグループにマッピングされているためとなり、想定された動作になります。

test009 ユーザーの動作

test009 ユーザーに関するマッピングは以下になります。

同様にアクセス パネルにサインインし、 OCI のアイコンをクリックします。

シングル サインオンの欄にある Continue をクリックします。

OCI コンソール画面にシングル サインオンできました。
同じようにコンソール画面の左ペインにある、「コンピュート」→「インスタンス」の順にクリックしてみます。

下記画面ショットのようにインスタンスの「リソースを表示する権限がない」と表示されていることが分かります。
test009 もコンピュートに関する権限が付与されていないのでこの動作は想定どおりです。

同画面の左ペインより、「ネットワーキング」→「概要」の順にクリックします。

ネットワーキングの画面にて「VNCウィザードの起動」をクリックします。

VNC の作成画面で VNC 名に任意の名前を入力し「次」をクリックします。

VNC の作成画面で画面左下の「作成」をクリックします。

仮想クラウド ネットワークが作成されました。と表示されました。左下の「仮想クラウド ネットワークの表示」をクリックします。

下記画面ショットのように TEST001 の仮想クラウド ネットワークが作成されていることが確認できます。

ここで重要なのは、仮想クラウド ネットワークの設定値ではなく、仮想クラウド ネットワークが作成でき表示の確認ができたことです。
test009 は下記ステートメントのとおり、ネットワーク関連のリソースを対象とするリソース タイプ「virtual-network-family」にたいして、すべての操作を行える権限「manage」を割り当てているためです。

Allow group Network-Operation-Group to manage virtual-network-family in tenancy

ここまでは想定された動作です、正しいステートメントに対して正しいグループ マッピングをした結果、想定された動作になりました。
最後に、 1 つの Azure AD ユーザーが複数の Azure AD グループにまたがった場合の動作を確認してみます。

test010 ユーザーの動作

test010 ユーザーに関するマッピングは以下になります。

test010 は Group002 にも Group003 にも所属しています。
そのため、OCI 側のグループ マッピングも 2 つのグループにまたがっていることが分かります。
この絵を見ただけでなんとなく想像はできると思いますが、実際に動作を確認してみます。

同様にアクセス パネルにサインインし、 OCI のアイコンをクリックします。

シングル サインオンの欄にある Continue をクリックします。

OCI コンソール画面にシングル サインオンできました。
同じようにコンソール画面の左ペインにある、「コンピュート」→「インスタンス」の順にクリックしてみます。

下記画面ショットのようにインスタンスのインスタンスの一覧が表示されていることが確認できます。

同画面の左ペインより、「ネットワーキング」→「概要」の順にクリックします。

ネットワーキングの画面にて「VNCウィザードの起動」をクリックします。

VNC の作成画面で VNC 名に任意の名前 (TEST002) を入力し「次」をクリックします。

VNC の作成画面で画面左下の「作成」をクリックします。

仮想クラウド ネットワークが作成されました。と表示されました。左下の「仮想クラウド ネットワークの表示」をクリックします。

下記画面ショットのように TEST002 の仮想クラウド ネットワークが作成されていることが確認できます。

これで test010 は test009 と同じ Group002 に所属していることからネットワーク リソースの操作ができることが確認できました。

Allow group Network-Operation-Group to manage virtual-network-family in tenancy

また「コンピュート」のインスタンス一覧が確認できたように、「コンピュート」リソースの操作ができることも確認できています。

Group003 は下記ステートメントのとおり、コンピュート関連のリソースを対象とするリソース タイプ「instance-family」に対して、すべての操作を行える権限「manage」を割り当てているためです。

Allow group Compute-Operation-Group to manage instance-family in tenancy

つまり、グループにまたがって所属している Azure AD ユーザーは OCI にマッピングされているそれぞれのステートメントに記載されているポリシーが割り当たる動作になります。

まとめ

Azure AD 側のユーザーが複数のグループにまたがって所属している場合、そのグループとマッピングされている OCI 側のグループに割り当てられたポリシーがAND 条件としてユーザーに付与されます。

今回の例で言うと、test010 はポリシー名「virtual-network-family」と「instance-family」両方の権限が利用できる動作になります。

この動作を避けたい場合は、Azure AD 側で複数のグループにまたがらないように管理するか、OCI とのマッピングを構成する際に、ポリシーが重複しないように設計する必要があります。

特に管理者権限を付与させたくない一般ユーザーの取り扱いについては意識する必要があります。

おわりに

今回は Azure AD と OCI が SAML 連携した環境において、Azure AD のグループと OCI グループをマッピングした場合に付与される IAM の動作を検証してみました。

前提として OCI にシングル サインオンできる Azure AD ユーザーは Azure AD 側の「ユーザーとグループ」に明示的に割り当てられたユーザーもしくはグループに限定されます。

その上で、OCI 側にシングル サインオンした際に付与される権限を OCI コンソールの「グループ マッピング」で定義する必要があります。
この定義を適切に行わないと、本来コンピュートの操作をさせたくないユーザーに対して必要以上の権限が割り当たってしまう動作が起こりうるので、そこを意識してグループ マッピングを定義しましょう。

また、複数のグループまたがった Azure AD ユーザーがいる場合は、AND 条件で権限が付与されるので、こちらの点も押さえておくポイントになります。

今回の記事が少しでも参考になれば幸いです。