この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
現在、自分はProfllyというプロフィールビューアーサービスの開発を行っています。
Profllyでは、サービスのIDaaSとしてAuth0を採用しています。
先日、Profllyで利用しているAuth0のテナントを移行する機会があったので、その移行記録をブログにしてみます。
Auth0テナント移行のざっくりとした流れ
今回、Auth0のテナント移行は主に以下のような流れで実施しました。
- 移行元Auth0テナント情報のエクスポート
- 移行先Auth0テナントへのインポートおよび事前設定作業
- Auth0テナント切替実施
それでは、以下よりそれぞれのフェーズで実際に行った作業を見ていきます。
移行元Auth0テナント情報のエクスポート
できるだけスムーズにAuth0テナントを移行できるよう、まずは移行元となる既存Auth0テナントで設定されている情報をエクスポートしてみます。
Auth0は、Auth0 Deploy CLIというツールを利用することでテナント設定をエクスポート/インポートできます。
上記のエントリを参考にして、既存のAuth0テナントの設定をエクスポートしていきます。
まずは、既存テナントでエクスポート用のM2Mアプリケーションを作成します。
次に、Auth0 Deploy CLIでエクスポートするための設定ファイル（json）を準備します。
auth0-export-config.json
{
"AUTH0_DOMAIN": "<エクスポートするAuth0テナント>.auth0.com",
"AUTH0_CLIENT_ID": "<作成したM2MアプリケーションのCLIENT_ID>",
"AUTH0_CLIENT_SECRET": "<作成したM2MアプリケーションのCLIENT_SECRET>",
"AUTH0_ALLOW_DELETE": false
}それでは、Deploy CLIを使ってテナント設定をエクスポートしてみます。
Deploy CLIがインストールされてない場合は、以下にてインストールできます。
$ npm install -g auth0-deploy-cli以下のコマンドでエクスポートを実行します。
$ a0deploy export -c auth0-export-config.json -f yaml -o settings/auth0/エクスポートを実行すると、以下のようなyamlとして既存のAuth0テナント設定がエクスポートされました。
settings/auth0/tenant.yaml
rules: （一部省略）
rulesConfigs: []
hooks: []
pages: []
resourceServers: []
clients:
- name: API Explorer Application
app_type: non_interactive
（以下省略）また、ActionsやRulesで設定しているjsのコードもエクスポートされています。
$ tree settings/auth0/
settings/auth0/
├── actions
│ └── <action_name>
│ └── code.js
├── rules
│ ├── <rule1>.js
│ ├── <rule2>.js
│ └── <rule3>.js
└── tenant.yaml移行先Auth0テナントの設定
次に、移行先のAuth0テナントの設定を行っていきます。
既存Auth0テナント情報のインポート
先ほどエクスポートした情報を元に、移行先のAuth0テナントへ設定をインポートしてみます。
上記エントリを参考に、エクスポートの時と同じくDeploy CLIを使ってインポートを行います。
移行先のAuth0テナントでも、インポート用にM2Mアプリケーションを作成しておきます。
作成後、エクスポートの時と同様にDeploy CLIの設定ファイルを準備します。
auth0-import-config.json
{
"AUTH0_DOMAIN": "<インポート先のAuth0テナント>.auth0.com",
"AUTH0_CLIENT_ID": "<作成したM2MアプリケーションのCLIENT_ID>",
"AUTH0_CLIENT_SECRET": "<作成したM2MアプリケーションのCLIENT_SECRET>",
"AUTH0_ALLOW_DELETE": false
}次に、先ほどエクスポートした情報そのままではインポートできない箇所があるので、事前にyamlファイルを修正しておきます。
今回は、audience周りで既存テナント -> 移行先テナントへの修正が必要でした。
settings/auth0/tenant.yaml
（以上略）
clientGrants:
- client_id: API Explorer Application
audience: https://<移行先Auth0テナント>.auth0.com/api/v2/
scope:
（以下略）インポートの準備ができたので、以下のコマンドで移行先Auth0テナントに向けてインポートを実行します。
$ a0deploy import -c auth0-import-config.json -i settings/auth0/tenant.yamlAuth0のコンソールを覗いてみると、各種設定がうまくインポートされているようです。
エクスポート対象外のテナント情報の設定
Auth0 Deploy CLIはテナント全ての設定をエクスポート/インポートできるわけではないので、一部の設定についてはDeploy CLIを使わずに設定を行う必要があります。
（Deploy CLIで扱える設定については、詳しくはこちらを参照してください）
今回の移行では、コンソール上で手動にて設定を行うこととし、具体的には以下について追加の設定を実施しました。
- Actions -> Custom Actionsに設定されているSecretsを追加
- Rules -> Settingsの各種KeyValueを追加
- Extensions -> 既存テナントで利用していたExtensionを追加
以上で、事前に準備可能な移行先Auth0テナントの設定は完了です。
テナント切替実施
最後に、サービスを一時停止してAuth0のテナント切替を行います。
アプリケーションのデプロイ&データマイグレーション
まず、Auth0のテナント移行の影響を受けるソースコード修正のデプロイやデータのマイグレーションを実施します。
（こちらについては、Auth0のテナント移行には直接関係がないので割愛します）
カスタムドメインの切替
今回移行対象となるテナントではAuth0にカスタムドメインを適用していますので、テナントのカスタムドメインの切り替えを実施します。
はじめに、既存テナントに設定しているドメインを削除します。
次に、移行先テナントで新たにドメインを設定します。
ドメインを設定すると、CNAMEレコードが表示されます。
今回の環境ではRoute53でドメインを取得しているので、そちらに登録済みレコードを表示されているCNAMEレコードの情報で書き換えます。
最後に、Auth0側でVERIFYしてカスタムドメインの切り替えは完了です。
Azure ADのSAML構成変更
今回移行対象となるテナントでは、Azure Active Directory（Azure AD）とAuth0を組み合わせたSSOとしているため、Azure AD側のSAML構成も一部変更する必要があります。
（補足： Azure ADによるSSOは検証のため今回移行対象となる環境でのみ有効にしており、公開中のProfllyでは現在ID/Password認証以外の認証方法はサポートしていません）
テナント名が変更になるため、SAML構成におけるEntity IDを以下のように修正します。
Entity ID: urn:auth0:<移行先のテナント>:<AzureADを設定したConnection>
これにて、Auth0テナントの移行作業は全て完了しました！
あとは、アプリケーション側で問題なく動作するか確認を行います。
おわりに
Auth0のテナントを移行する機会があったので、Auth0 Deploy CLIツールを活用しつつテナント移行を実施した一部始終を書きました。
実際の移行作業においては、アプリケーション側の変更で一部考慮不足や設定漏れがあり、すんなりとは行きませんでしたが、Auth0の設定に関しては上記に書いた手順にてうまく移行することができました。
また、Auth0 Deploy CLIを利用することでAuth0テナントの設定ファイルをリポジトリ管理できそうなので、今後はAuth0テナントの設定情報はリポジトリで管理しつつ、Dashboard上の最新情報と齟齬が出ないような仕組みを考えていきたいと思います。
現在Profllyチームでは、一緒にサービスを成長させていくためのプロダクト開発エンジニアを募集しています。
もし興味のある方は、以下をご覧いただけると嬉しいです！
9
