ドメイン間のOCI IAMオブジェクトの移行 (2022/09/01)

https://blogs.oracle.com/post/iam-domain-migration

投稿者： Callan Howell-Pavia | OCI Solution Architect

OCI Identity and Access Management Domains は、OCI アクセスと他のアプリケーションのアクセスを管理する豊富な機能を備えたアクセス管理ソリューションを提供します。

OCI Identity and Access Management (OCI IAM) のほとんどの設定は1回限りの操作で、自動化する意味はあまりありませんが、アイデンティティとアクセス管理は、アプリケーションのソフトウェア開発ライフサイクル (SDLC) に組み込むべき要素としてますます重要性を増しています。あなたの特定の SDLC の実装に依存して、これはより高い環境に IAM 設定を促進するメカニズムが必要かもしれません; 新しいテスト環境にユーザのサブセットを持つ別の環境を作成するなど。さらに、さまざまなシナリオや再アーキテクチャにより、インスタンス間でユーザーや設定の移行が必要になる場合があります。

このような要求に応えるため、IAMインスタンス間のユーザー、グループ、および各種設定オプションの移行プロセスを簡素化するためのユーティリティを用意しました。これらのユーティリティは、GitHubのiam-samplesリポジトリ[こちら](https://github.com/oracle-samples/idm-samples/tree/master/iam-domain-migration-utilities)の一部として公開されています。

各ユーティリティの詳細な説明は、そのリポジトリで提供されているので、この投稿では、いくつかの一般的なシナリオでそれらをどのように利用できるかを説明します。

この記事の執筆時点では、IAMドメインとIDCSベースの両方のテナントを持つ顧客が存在します。コンソールの外観は異なりますが、これらの手順とユーティリティは、両方のタイプのIAMに適用できます。

初期設定

これらのユーティリティは Node.js を使って書かれているので、(nodejs.org)[https://nodejs.org] から取得できる Node.js ランタイムのコピーが必要です。リポジトリからユーティリティを取得したら、'iam-domain-migration-utilities' ベースディレクトリで `npm install` を実行して、依存関係をインストールできます。

移行作業を行うには、移行元と移行先の両方のインスタンスの設定情報をJSONオブジェクトとして、以下のような形式の設定ファイルに記述する必要があります。

{
  "source":{ "client_id": "1234567",
    "client_secret": "source-secret",
    "base_url":"https://idcs-<source-guid>.identity.oraclecloud.com"
  },
  "target":{
    "client_id": "12334567",
    "client_secret": "target-secret",
    "base_url":"https://idcs-<target-guid>.identity.oraclecloud.com"
  }
  }

Base URLはDomain Overviewから取得することができます。

移行を容易にするため、各インスタンスで新しいアプリケーションを作成し、ここで参照されるクライアント ID/secret を提供することをお勧めします。これらのアプリケーションは、IAM の Confidential Application であり、以下の構成で作成されます。

スクリーンショットが不明瞭な場合、以下に関連する設定を示します（設定について言及されていない場合は、デフォルトで問題ないと考えてください）。

Application Details:

              Name: <Name>

              Description: Client for migration

Configure OAuth:

              Resource Server: Skip

              Client:

                             Allowed Grant Types: Client Credentials

                             Add app roles: Yes

                             Roles: Identity Domain Administrator

Policy: Skip

ユーティリティは、管理者ロール「Identity Domain Administrator」を持っていると仮定していますが、コマンドによってはそのロールに関連するすべての権限が必要なわけではありません。これは非常に幅広い権限であることを考えると、移行が完了した後にアプリケーションを非アクティブにしたり削除することは理にかなっています。

シナリオの例

以下の章では、このユーティリティの使い方の概要と、効率的なコマンドの例を示します。すべてのコマンドは `-d` と `-v` オプションをサポートしており、それぞれ `--dry-run` と `--verbose` を意味します。これらのオプションを使用して、コマンドを実行する前にその動作を確認することが推奨されます。

全ユーザーを別ドメインに移行

IAMはデフォルトでフラットファイルのインポート/エクスポート機能を提供しており、これは大量のユーザーオンボーディングや、アクセスレビューなどの目的で多用されており、大規模なユーザー移行に対応するために使用することができます。

このユーティリティは、このエクスポート機能を利用し、User Schema 拡張の一部として設定された属性を含む、ユーザーに関するあらゆる属性を確実に取得するための追加ユーティリティでラップしています。

ユーザーの移行は、通常、ソースからユーザーとグループを最初にエクスポートし、その後、ターゲット環境にインポートするという、2段階のプロセスで行われます。移行ユーティリティは、次のコマンドを使用して、ユーザーのエクスポートを初期化することができます。

node migrate-iam export-users --config ./config.json

このようにデフォルトの引数で実行すると、すべてのカスタムユーザー属性をエクスポート可能にし、エクスポート可能なすべての属性をエクスポートするExport Usersジョブが開始されます。エクスポートジョブのプロセスはコンソールで確認することができます。

異なるシナリオで使用できる追加オプションが多数あります。移行を実行していて、ユーザーにパスワードのリセットをさせたくない場合は、以下を使用することができます。

node migrate-iam export-users --config ./config.json –include-passwords

サイレントマイグレーションを実行する場合、結果の CSV エクスポートで 'ByPass Notification' カラムをすべてのユーザーに対して true に設定するか、インポート時にターゲットインスタンスの Notification を一時的に無効化する必要があります。

エクスポートジョブが完了すると、コンソールからファイルをダウンロードすることができます。

その後、ターゲットインスタンスにインポートします。

インスタンス間の移行には、組み込みのグループエクスポート機能を使用できます。グループエクスポートをソースインスタンスのコンソールまたはAPIから実行し、ユーザーのインポートが完了した後にターゲットにインポートすると、ターゲットでグループを作成し、ユーザーをそれらに割り当てることができます。

注：100,000人以上のユーザーをエクスポートする場合、User Importは一度に100,000行という制限があるため、手動でファイルを分割する必要がある場合があります。

設定を上位環境にプロモートする(T2P)

このユーティリティは、上位の環境への設定の自動プロモートを行うためのツールを提供します。これには、上位環境のIAMにアプリケーションの表現を作成することと、アプリケーション専用のサインオン・ポリシーやその他の設定を作成する可能性があります。

アプリケーションがグループを利用し、グループが割り当てられている場合、手動、API、またはグループのインポート/エクスポートを介して、ターゲットインスタンスで最初にこれらのグループを作成する必要があります。移行ユーティリティはグループ名でグループへのグラントをマッピングするので、環境間で異なる名前のグループを使用している場合、移行後にグループを再割り当てする必要があるかもしれません。

ターゲット・インスタンスでのアプリケーションの作成は、以下のコマンドで行います。

node migrate-iam migrate-app <app-id> --config ./config.json --set-inactive

ここで参照されるapp-idは、APIやコンソールから取得できるアプリケーションIDです。

このコマンドを実行すると、ソース環境が検査されてアプリケーションの依存関係が判断され、ターゲットインスタンスで再作成されて再リンクされます。

このコマンドを実行すると、アプリケーションの表現がターゲットのIAMインスタンスに作成されます。しかし、そのIAMインスタンスに依存する実際のアプリケーションは、新しいインスタンスを使用するように再設定する必要があります。これには、URL、client_id/secrets、SAMLメタデータなどを更新することが一般的である。このコマンドは、単にインスタンス間でIAMの設定をコピーするだけです。

IAM コンポーネントのマイグレーションをより大きな SDLC プロセスに適合させる方法をさらに制御するために、このコマンドは `--set-inactive` オプションを受け付けます。指定すると、ソースアプリのアクティブ化のステータスは無視され、アプリケーションはターゲットインスタンスで非アクティブ化された状態で作成されます。これにより、アプリをログインの有効なターゲットとして設定する前に、追加の設定、テスト、その他の移行タスクを実行することができます。

このコマンドは、べき乗ではないことに注意してください。ターゲット内のアプリケーションがすでに存在する場合は、更新されず、新しいものが作成されます。

このアプリケーションに対して特定のサインオンポリシーが設定されている場合、次のコマンドを使用してターゲットインスタンスに昇格させることもできます。

node migrate-iam migrate-sign-on "App Sign-On Policy" --config
./config.json

ここで、「App Sign-On Policy」は、ソース・インスタンスで作成されたサインオン・ポリシーの名前です。

このコマンドを実行すると、ターゲット・インスタンスで潜在的な非互換性がチェックされ、その後、ポリシーが作成されます。ただし、アプリケーションは新しいサインオンポリシーに自動的に割り当てられないため、コンソールまたはAPIのいずれかを使用してポリシーを作成した後に、これらを割り当てる必要があります。

下位の環境がテストユーザーの IP 許可リストにネットワーク境界を使用している場合、これらのネットワーク境界は、アプリとポリシーの依存関係であるため、上位の環境に移行されます。アプリケーションのカットオーバーの前に、この構成を検証することをお勧めします。

テスト用の新しい環境にアプリをクローン

アプリの変更をテストするために新しい環境を作成するプロセスは、おそらく上記の2つのシナリオの組み合わせになります。新しいテスト環境では、アプリケーションとサインオンの構成だけでなく、テストユーザーも必要になるからです。

ユーザーとグループのエクスポートは、ほぼ同じ方法で実行できますが、ソースからユーザーのサブセットのみをエクスポートすることが望まれます。これを実現するには、`--filter` オプションを使います。

node migrate-iam export-users --config ./config.json –filter 'groups[value eq \"<group-id>\"]'

この場合、同じエクスポート ジョブが起動されますが、フィルターで指定されたグループに属するユーザーだけがエクスポートされます。

その後、CSV エクスポートをソースから抽出し、新しい環境にインポートすることができます。

その後、アプリケーションを移行することができます。

node migrate-iam migrate-app <app-id> --config ./config.json

これが以前の設定のない新しいIAMインスタンスであると仮定すると、Sign-On Policyがそれに依存している場合、MFA設定を移行することが望ましいかもしれません。

node migrate-iam migrate-mfa --config ./config.json

また、アプリケーションに関連するサインオン・ポリシーも同様です。

node migrate-iam migrate-sign-on "App Sign-On Policy" --config ./config.json

これを実行した後、新しいインスタンスの Sign-On Policy に App を手動で割り当てる必要があります。

この結果、ターゲットに複製されたソース構成の小さなスライス、テストユーザーのセット、アプリケーションの表現、およびサインオン構成が作成されます。これにより、アプリケーションのコピーをこの新しい環境に対して一時的にテストし、必要に応じて構成を再インクルードまたは破棄することができます。

その他のシナリオ

これらの例は、いくつかの基本的な使用例について説明していますが、これらのユーティリティは多くの柔軟性を持っています。私は、すべてのコマンドとそのオプションの詳細を含むリポジトリ内のReadmeを確認することをお勧めします。OCI IAMの詳細については、製品のWebページを参照するか、サービスの詳細なドキュメントにアクセスしてください。