Service Catalog Managed Application v0.2.22.1122

組織内で Microsoft Azure なマネージドサービスを 提供し、管理・運用を委託するための Service Catalog Managed Application の紹介資料です。
https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/managed-applications/overview

Azure Marketplace にソリューションを展開する MS パートナー企業は既にノウハウを持っているかもしれませんが、一般的な Azure ユーザー企業にはあまりなじみの無い機能だと思います。マーケットプレイスに出せないユーザー企業にとっては機能が多少限定的にはなりますが、サービスカタログという種類のマネージドアプリケーションを開発・展開することが可能です。公式ドキュメントには記載されていないことも多かったため、調査検証した内容を共有します。

Transcript

1. Ayumu Inaba Cloud Solution Architect Microsoft Japan Service Catalog Managed Application 1
2. 目次 利用者 ： マネージド アプリケーションのデプロイ 発行元 ： マネージド アプリケーションの設計と定義の作成 まとめと補足 マネージドアプリの開発（利用）には、下記に関する基本的な 知識が必要になる Azure Resource Manager Azure Resource Manager テンプレート Azure RBAC : Role Based Access Control 2
3. 概要 本資料では組織内の利用者向けにソリューションを展開する サービスカタログ マネージド アプリケーションについて解説 Azure Managed Application を使用することで組織内の「サービスカタログ」に発行する ことも、Azure Marketplace を介して外部に展開することも可能 ただし本書では Azure Marketplace に展開するパターンは対象外とする 3
4. テンプレート スペック サービスカタログ マネージド アプリ 一般的な SaaS マネージド アプリケーションの用途 同一組織内向けに提供される“マネージド サービス”を提供・利用する ことが出来る ここでいう「同一組織」とは同じ Azure AD テナントに所属するユーザーやサブスクリプションという意味合い 発行元はマネージド アプリケーションの“定義”を共有し、組織内の利用者はそれを元に自信のサブスクリプショ ン内にサービスをデプロイできる Azure の課金は利用者側サブスクリプションで発生するが、発行元がアクセス権を持ち管理・運用が可能 4
6. ユーザーエクスペリエンスの確認 初めに利用者側の始点から理解する とメリットがわかりやすい ここで作成・設定される内容を確認しておくと、発行元で定 義を作成する内容が見えてくる 利用者は大まかには ２ つのアクセス権が必要 同一の Azure AD テナントで共有されている 「定義」 に対する 閲覧権限が必要 Microsoft.Solutions/applicationDefinitions/read Reader ロール等 に含まれる その定義から作成されるマネージド アプリケーションをデプロイす るためのサブスクリプションのアクセス権 Microsoft.Resources/subscriptions/resourceGroups/* Microsoft.Solutions/applications/* など Owner, Contributor, Managed Application Contributor ロー ル 等に含まれる Azure 組み込みロール - Azure RBAC | Microsoft Learn 6 Deploy
7. Step 1 : マネージド アプリの定義を確認 マネージド アプリケーション センターから閲覧可能なサービス カタログ アプリケーション定義を探す メニューにマネージド アプリケーション センターが表示されてない場合は、「全てのサービス」 からお気に入りに追加する 7
8. Step 2 ： マネージド アプリをデプロイ 定義の画面でデプロイボタンを押下すると通常の Azure リソース と同様にデプロイすることができる ２つのリソースグループが必要になることに注意 アプリケーション リソースグループに対して「マネージド アプリケーション」をデプロイする権限が必要 サブスクリプションに対して新規に マネージド リソースグループを作成できる権限が必要 8
9. Step 2 ： マネージド アプリをデプロイ アプリケーションのデプロイ パラメタを入力する この例では VNET 統合された PostgreSQL Flexible Server を含むマネージド アプリケーション をデプロイしている このため事前に準備してある VNET や Private DNS Zone を参照している 9 Microsoft.Network.VirtualNetworkCombo Microsoft.Solutions.ResourceSelector Microsoft.Common.TextBox Microsoft.Common.PasswordBox createUIDefinition.json
10. Step 3 : マネージド アプリのデプロイ開始 指定したアプリケーション リソースグループ に対して マネー ジド アプリケーションがデプロイされる ただしここで含まれているのは Microsoft.Solutions/applications 型のリソースが１つだ け指定されている 10
11. Step 4 : マネージド アプリの実体のデプロイ マネージド リソースグループ に対しては、アプリケーションの 実体となる1つ以上のリソースがデプロイされる この例では PostgreSQL Flexible Server とバックアップ用の Storage Account が出 来上がっていることがわかる 11
12. Step 5 : 出来上がり マネージド アプリケーションの画面にはユーザー が利用するために情報を出力されている ここではアプリの説明、PostgreSQL や Storage の接続情報、参照でき るメトリックなどが確認できる 実体を格納したマネージド リソースグループ も参照可能だが、こちらは閲 覧のみで触らない 12
13. Step 6 : 利用終了 使用しなくなったマネージド アプリケーションを削除する 実体となるリソースおよびそれらを格納するマネージドリソースグループも削除されるため課 金も停止される 利用者は任意のタイミングで開始・終了できるため、通常の従量課金型クラウドサービスを同 じような感覚で利用可能ということ 13
14. デプロイメントの裏側 マネージド リソースグループ への実体リソースのデプロイは Appliance Resource Provider によって行われる マネージド リソースグループ自体は利用者が作成したが、中身は特殊なサービス プリンシパルによっ て実行されていることがわかる 直接ユーザーが作成権限を持たないリソースも間接的にデプロイできる（＝デプロイの代行） 併せて発行元のユーザーやグループに対してロールの割り当てが行われる（＝管理作業の委託） またユーザー自身に対してはアクセスが閲覧権限のみに制限される（＝想定外作業の抑止） 14
15. Customer サブスクリプション アクセス権の全体像 Publisher サブスクリプション Definition Managed Application
16. マネージド リソースグループのアクセス権 割り当て／拒否の割り当てを確認すると、発行元へ管理を委 託している状況が理解できる 利用者はサブスクリプションから継承した権限を保有しているが、 */read 以外の操作をする 権限が剥奪されている 発行側で指定した運用担当者に対して必要なロールが割り当てられているが、拒否の割り 当てからは除外されている 16
18. マネージド アプリの設計と開発 ユーザー側で可能なこと不可能なことを整理すると、発行側 で考慮すべき内容が見えてくる マネージド アプリの実体となるリソースをデプロイするための ARM テンプレート（必須） Azure Portal からデプロイするためのユーザーインタフェース（必須） デプロイ後のマネージド アプリケーション 画面に表示するためのユーザーインタフェース マネージド リソースグループ内部に直接アクセスする運用担当者と要求するロール 利用者に許可するマネージド リソースグループ内部への操作 マネージドアプリケーションの定義には上記の設定を組み込 む必要がある マネージドアプリケーションの定義自体も Azure リソースであるため、利用者には参照権限 をもつ RBAC ロールを割り当てることが出来る このため発行元と利用側の双方のサブスクリプションと各ユーザーが同一 Azure AD テナ ントに所属している必要がある 18
19. マネージド アプリ 定義の作成 まず以下のファイルを zip で固めたパッ ケージを作成 mainTemplate.json マネージド アプリケーション の実体をデプロイするテンプレート createUiDefinition.json 上記のテンプレートに渡すためのパラメタを構築する viewDefinition.json マネージド アプリケーションをポータルで表示する画面定義 このファイルは必須ではないので作らなくても良い マネージドアプリケーション定義リソース を作成 上記のパッケージファイルの URL をパラメタとして指定 発行元や利用者に割り当てるアクセス制限はこちらで指定 19 Zip File viewDefinition .json createUiDefinition .json mainTemplate .json Microsoft.Solutions/applicationDefinitios - 利用者のアクセス制限と許可 - 発行元の運用担当と要求するロール - パッケージファイルの URL
20. mainTemplate.json の作成 一般的な ARM Template の開発と同じであるため、まずは 単体で開発・テストしておく ARM Template や作成方法については省略（公式ドキュメントを参照） 複数ファイルに分割したリンク済みテンプレート として作成しないこと 最終的に mainTemplate.json という１つのファイルにまとめる必要があるため テンプレートが複雑になりファイルを分割して管理したい場合は Bicep で実装するとよい モジュール分割した Bicep ファイルをコンパイルすると入れ子になったテンプレートとして単一ファイルになる テンプレートの記述も Bicep の方が簡易であり、各種ツールのサポートも充実しているため生産性も高い 20 mainTemplate.bicep module1.bicep module2.bicep Compile mainTemplate.json
21. mainTemplate.json の作成 テンプレート デプロイ時の入力パラメータは後述の UI 定義 の出力を受け取る この段階でユーザー インタフェースまで意識する必要はないが、各種リソースのパラメタはテ ンプレート内部で演算することで、なるべくパラメータ数を減らしてシンプルにすると良い テンプレート出力結果はデプロイ後に Azure Portal で表示されるため、「アプリケーション」 利用者に必要な情報を出力する（ＵＲＬや接続キーの情報など） 21 mainTemplate .json
22. createUiDefinition.json の作成 マネージド アプリをデプロイするために必要なパラメータを入力す るための画面を定義 JSON スキーマや各種項目の詳細は公式ドキュメントを参照 basics は共通の必須項目となる最初のタブを定義する（デフォルトのままでも良い） stepｓ 内に入力項目を指定、複数の step を定義した場合はタブが分かれる outputs の項目は mainTemplate.json の parameters と合わせる step や basics の内容からマッピングする 22
23. createUiDefinition.json の作成 各 step はタブを構成し、step 内の element 要素によって入力 項目が表示される step は name, type, label, toolTip 等で構成される要素（オブジェクト）の配列 特に label, toolTip, type を適切に選択することでユーザーが快適に利用できる ユーザーインタフェース要素は多数用意されているため、適切なものを選択すると良い 23 “stepｓ”: [ { “name”: “postgreConfig”, “label”: “PostgreSQL settings”, “elements” : [ { “name”: “userName”, “label” : “Admin User Name”, “toolTip”: “Input your name”, “type” : “Microsoft.Common.TextBox” }, { “name”: “password”, “label” : “Admini User Password”, “toolTip”: “more than 12 alpha numeric char” “type” : “Microsoft.Common.PasswordBox” }, }, { step }, { step }, … ] ] steps stepのlabel element の type で 表示が変わる element の label Step 数分のタブが並ぶ element 数の入力項目が並ぶ
24. createUiDefinition.json の作成 ユーザー入力の結果（outputs）は mainTemplate.json のデプ ロイ時に parametes として使用されるオブジェクトにする Key は parameters の型と名前に合わせ、Value は 各入力項目から抽出する 基本パターンは steps(‘step-name’).elementName.property 24 “outputs” : { "region“ : "[location()]", "postgreServerName“ : "[steps('postgreConfig').postgreServerName]", "adminName“ : "[steps('postgreConfig').adminName]", "adminPassword“ : "[steps('postgreConfig').adminPassword]", "postgreVnetResourceGroup": "[steps('postgreConfig').targetVnet.resourceGroup]", "postgreVnetName": "[steps('postgreConfig').targetVnet.name]", "postgreSubnetName": "[steps('postgreConfig').targetVnet.subnets.subnet1.name]", "privateDnsZoneId": "[steps('postgreConfig').privateDnsZone.id]" } outputs { “parameters” : { “region” : { “type”: “string” }, “postgreServerName” : { “type”: “string” }, “adminName” : { “type”: “string” }, “adminPassword” : { “type”: “secureString” }, “postgreVnetResourceGroup” : { “type”: “string” }, “postgreVnetName” : { “type”: “string” }, “postgreSubnetName” : { “type”: “string” }, “privateDnsZoneId” : { “type”: “string” } } mainTemplate.json 項目を合わせる
25. createUiDefinition.json の作成 スキーマに則った JSON の記述は大変で、実際の画面出力 が想像しにくい（ので項目数は減らした方が楽） サンドボックス環境を使って表示内容を確認しつつ作業を進める デプロイを試さなくて良いので気軽に Ｔｒｙ＆Ｅｒｒｏr 出来る 25 この画面で createUiDefinition.json の作業を進めると良い 実際の動作を確認 出力も確認できる
26. マネージド アプリ定義のデプロイ 定義自体もテンプレートでデプロイする方 法がおススメ 最初は Azure Portal を使うと設定項目がわかりやすいが、何 度も試すには向いていない Azure CLI によるデプロイは指定できないパラメータがあるた め最終的に使いにくい ARM Template ないしは Bicep であれば、使用可能なパラ メタがすべて利用可能 26
27. マネージド アプリ定義のデプロイ lockLevel プロパティで利用者にマネージド リソースグルー プへのアクセスを許可するか否かを決める lockLevel : None 拒否の割り当てが行われないため、サブスクリプションから継承したままの操作が可能になる マネージドアプリケーションはデプロイの代行として利用し、その他のリソースと同様のアクセス制御とする lockLevel : ReadOnly 参照以外のすべての操作に対して拒否の割り当てが行われる 発行元に全ての管理と運用を委託し、利用者はアプリケーションとしての機能のみを使用する 27 lockLevel : None の拒否割り当て lockLevel : ReaｄOnly の拒否割り当て
28. マネージド アプリ定義のデプロイ lockingPolicy を使用することで、ReadOnly であっても部 分的な操作のみを利用者に許可することが出来る 夜間の仮想マシンの停止、バックアップ・リストアなど、利用者のタイミングで実行したい操作 など全てが出来なくなってしまう 拒否割り当てにおける除外条件として働くので、サブスクリプションから継承していない操作 が可能になるわけでは無い 28 lockLevel: ‘ReadOnly’ lockingPolicy:{ allowedActions: [ 'Microsoft.DBforPostgreSQL/*' ] allowedDataActions: [] } テンプレートで指定 元々が Contributor や Owner だった場合 - */read 操作は拒否されないので、全て のリソースの参照が可能 - PostgreSQL/* 操作は拒否されないの で、PostgreSQL の操作は全て可能 - それ以外のリソース操作は全て拒否 元々が Managed Application Contributor だった場合 - */read 操作は拒否されないので、全て のリソースの参照が可能 - PostgreSQL/* 操作はもともと許可さ れていないため、PostgreSQL の操作 は実施できない - それ以外のリソース操作は全て拒否
29. マネージド アプリ定義のデプロイ 発行元の運用担当者に対してマネージド リソースグループ への ロールを割り当てて、実際の管理・運用の操作が行えるようになる principalId : 運用担当者のユーザーやグループの ObjectID roleDefinitionId : 割り当てる RBAC ロールの DefinitionId の確認 役割に応じて複数設定することも可能（監査担当が Reader ロール、運用担当は Contributor ロール、など） 29 authorizations: [ { principalId: ownerPrincipalId roleDefinitionId: ownerRoleId } { principalId: contributorPrincipalId roleDefinitionId: contributorRoleId } ] # ユーザープリンシパルの ObjectId ＞ ＄upn = ‘useralias@domain.name.com’ > az ad user show –id $upn --query 'id’ 0b8xxxxx-edxx-4bxx-81xx-a6d6dxxxxxxxx # RBAC ロールの ID を確認 > $mrgrole = 'Storage Blob Data Owner' > az role definition list -n $mrgrole --query '[].name' b7e6dc6d-f1e8-4753-8033-0f276bb0955b テンプレートで指定 PowerShell
30. 補足 : 利用者に割り当てられるアクセス権 “拒否”の割り当てにおける “NotAction” は「拒否しない」ということ lockLevel : ReadOnly は RBAC において DenyActions ： NotAction として反映される lockingPolicy.AllowdAction も RBAC において DenyActions ： NotAction として反映される 30 Read Write Delete Update Authorize Read Write Delete Update Authorize Read Write Delete Update Authorize サブスクリプションスコープで 割り当てられた権限 lockLevel : None lockLevel : ReadOnly lockLevel : ReadOnly + lockingPolicy.AllowedAction Read Write Delete Update Read Action : * Read Action : * NotAction : Update, Authorize Update ※ チュートリアルなどで紹介さ れているのはこのパターン マネージド リソース グループに対する権限 ※ AllowdAction で追加の権限 （Authorize）が付与されるわけではない Authorizations オプションで指定された「運用担当」は lockLevel や lockingPolicy の対象外 ＝ RBAC の設定を見ると「拒否の割り当て」から除外されて設定される
31. 利用者への共有 作成したマネージド アプリケーションの定義に対して、利用者 の読み取り権限を付与すれば利用可能になる この画面を表示している際にブラウザで表示されている URL が定義リソースへのダイレクト リンクになっているため、利用者にメールやチャットなどで連絡するとすぐに利用できる マネージド アプリケーション センターにも定義が表示される 31
32. 補足 : 利用者から見たアクセス権付与の透明性 利用者もデプロイ後に設定されるア クセス権は確認できる マネージドアプリを暗黙的にデプロイできる権限を持 つ Contributor や Owner なら理解できる（はず） 明示的にデプロイ権限を付与されている Managed Application Contributor も理解できる（はず） ただ現実問題としては発行元から共有時に積極的に 説明したほうが親切 32
33. 利用者と管理対象の確認 発行元はマネージド アプリケーション センターから、現在利用 されている状況が確認できる マネージド アプリケーション、マネージド リソースグループ、デプロイに使用した定義が確認 可能になっているので、ここを起点に運用作業を行う 管理外のサブスクリプション（の一部）に対してアクセスが可能になってしまうため、最小特権 の原則に留意して設定すること 不必要に強い権限を持たない、不必要なユーザーやアプリに権限を付与しない 人的な管理はミスを発生しがちなため自動化も併せて検討するとよい 33
35. Zip File Customer Subscription Customer サブスクリプション Managed Application の全体像 Publisher サブスクリプション Definition createUiDefinition .json mainTemplate .json Managed Application
36. 補足 ： AKS と似ている？ Azure Kubernetes Service と構造的には類似しているが 仕組みが異なる AKS もマネージドクラスタと呼ばれるリソースグループと、VMSS、Load Balacner、 Storage、Application Gateway 等のリソースを管理するサービス構成 ただし AKS の場合は利用者が明示的に指定および権限付与したサービスプリンシパルや マネージド IDを使用して制御するため、利用者側に Owner 等の強い権限が必要 36
37. Managed Application Contributor ロール マネージド アプリケーションをデプロイする利用者にはそれほど多く の権限は必要ない 最低限必要な操作は Managed Application Contributor ロールに含まれている 大まかには マネージド リソースグループを作成するための権限と、マネージド アプリケーションをデプ ロイする権限があればよい アプリケーションの実体リソースを作成・制御するための権限は必要ない（Appliance Resource Provider が代行してくれるため） 37
38. Microsoft Confidential ◼ 本資料は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点でのマイクロソフトの見解を示したものです。状況等の変化により、内容は変更される場合があります。本資料 に特別条件等が提示されている場合、かかる条件等は、貴社との有効な契約を通じて決定されます。それまでは、正式に確定するものではありません。従って、本資料の記載内容とは異なる場合がありま す。また、本資料に記載されている価格はいずれも、別段の表記がない限り、参考価格となります。貴社の最終的な購入価格は、貴社のリセラー様により決定されます。マイクロソフトは、本資料の情報に対 して明示的、黙示的または法的な、いかなる保証も行いません。 © ２０２０ Microsoft Corporation. All rights reserved. Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。 38