天神サテライトへお引っ越ししました。
引っ越しして、周辺のお店がいろいろと変わったので
出社時のランチが毎回楽しみです。
今の一押しは焼き肉弁当！！
こんにちは。かとぅーんです。
マルチテナントでのAzureのアクセス管理について調べる機会があり、Azure Lighthouseを使ってみて
便利だなぁと感じた点があったので紹介したいと思います。
Azureではテナントごとの運用が基本なので、そのテナントを超えたレベルでの連携となると
ちょっととっつきにくく、えっとどっち？ってわかりにくい部分がありましたので
整理していきたいと思います。
マルチテナントでの操作で、まず思いつくのがゲストユーザーを招待する
Azure AD B2Bコラボレーションではないでしょうか。
招待されたユーザー側としては招待メールを確認し、テナントを切り替え
アクセスを行う必要があります。
ユーザーが大量になってくるといろいろとメンテナンスにコストがかかってきたり
いざ権限の変更を複数ユーザーに行おうとすると大変だったりします。
そんな時にAzure Lighthouse！
Azure Lighthouseとは
Azure AD B2Bコラボレーションに似ていますが、マルチテナントでアクセスする場合に
権限を委任させてアクセスする形をとります。
この委任するという点がポイントで、サブスクリプションやリソースグループのスコープに対して
アクセス権を委任して設定することで、アクセス管理のしやすさやテナントの切り替えなしに
アクセスできるなどの利点が生まれます。
現在アクセス可能な設定がどこなのか？など双方で視覚的に確認できたりと便利に使えます。
仕組みとしては
下図テナントB, C(顧客テナント)上で、下図テナントA（サービスプロバイダーテナント）の
テナントID, ユーザー/グループ/サービスプリンシパルのID, 組み込みロールID
をサービスプロバイダーのオファーとして登録、サブスクリプション/リソースグループへの委任を
デリゲートとして設定しアクセスできるようにします。
一例としてテナントA→テナントBへアクセス設定できるようにするケースで確認していきます。
サービスプロバイダー設定用のARMテンプレート作成
まず、サービスプロバイダー設定用のARMテンプレートを作成する必要があります。
- managedByTenantId：テナントAのテナントID
- principalId：ユーザー/グループ/サービスプリンシパルのID
- roleDefinitionId：組み込みロールID
のそれぞれのIDを設定します。
組み込みロールIDについては以下参考
Azure 組み込みロール - Azure RBAC | Microsoft Learn
{
"$schema": "https://schema.management.azure.com/schemas/2019-08-01/subscriptionDeploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"mspOfferName": {
"type": "string",
"metadata": {
"description": "Specify a unique name for your offer"
},
"defaultValue": "policyDefinitions"
},
"mspOfferDescription": {
"type": "string",
"metadata": {
"description": "Name of the Managed Service Provider offering"
},
"defaultValue": "policyDefinitions"
}
},
"variables": {
"mspRegistrationName": "[guid(parameters('mspOfferName'))]",
"mspAssignmentName": "[guid(parameters('mspOfferName'))]",
"managedByTenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"authorizations": [
{
"principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"roleDefinitionId": "36243c78-bf99-498c-9df9-86d9f8d28608",
"principalIdDisplayName": "Your Name"
}
]
},
"resources": [
{
"type": "Microsoft.ManagedServices/registrationDefinitions",
"apiVersion": "2020-02-01-preview",
"name": "[variables('mspRegistrationName')]",
"properties": {
"registrationDefinitionName": "[parameters('mspOfferName')]",
"description": "[parameters('mspOfferDescription')]",
"managedByTenantId": "[variables('managedByTenantId')]",
"authorizations": "[variables('authorizations')]"
}
},
{
"type": "Microsoft.ManagedServices/registrationAssignments",
"apiVersion": "2020-02-01-preview",
"name": "[variables('mspAssignmentName')]",
"dependsOn": [
"[resourceId('Microsoft.ManagedServices/registrationDefinitions/', variables('mspRegistrationName'))]"
],
"properties": {
"registrationDefinitionId": "[resourceId('Microsoft.ManagedServices/registrationDefinitions/', variables('mspRegistrationName'))]"
}
}
],
"outputs": {
"mspOfferName": {
"type": "string",
"value": "[concat('Managed by', ' ', parameters('mspOfferName'))]"
},
"authorizations": {
"type": "array",
"value": "[variables('authorizations')]"
}
}
}
そのほか、Azure LighthouseのARMテンプレートについて、各種サンプルコードについては
GitHubが参考になります。
github.com
ARMテンプレートに関しては、テナントA側で
ポータル/マイカスタマー/サービスオファー/[ARMテンプレートを作成]
から作成することも可能です。
サービスプロバイダーとして設定
ARMテンプレートが作成できたら、顧客テナント(テナントB)で
サービスプロバイダー/サービスプロバイダーのオファー
から、オファーテンプレートのアップロードで
オファー内容を記述したARMテンプレートをアップロードしカスタムデプロイを行います。
委任で、登録したサービスプロバイダーへ委任することで追加や削除ができます。
サービスプロバイダーのアクセスが不要になった際には
サービスプロバイダーのオファー画面上でオファーを削除することで
テナントAからのアクセスはできなくなります。
サービスプロバイダー側から確認
サービスプロバイダーとして設定されたテナントA側では、以下のように
委任されたディレクトリも含まれる形で表示されます。
そのため、テナントの切り替えなく委任されたテナントへのアクセスが
そのまま可能となります。
アクセスするテナントA側からは、マイカスタマー/顧客、委任で、サービスプロバイダーへと
登録されている顧客名などが一覧で表示されます。
こちらを確認することで、どの顧客への委任が設定されているかがわかります。
アクセス権を委任という形で設定しているため、principalIdにグループIDを指定することで
複数ユーザーで同一のアクセスを必要とする場合、テナントA側のグループにユーザーを
追加削除することでアクセスユーザーの管理が容易に行えるため
B2Bのようにゲスト招待を都度テナントB側に依頼する必要なく管理でき便利に使うことができます。
このような仕組みがAzure Lighthouseとなります。
Azure Lighthouseは、追加コストはかかりませんのでマルチテナントでのアクセス権管理の際には
是非利用してみてください。
