Azure で VM イメージを外部へ共有するには ～ 後編：イメージ共有編 ～

開発 Azure Cloud

こんにちは。インサイトテクノロジーの松尾です！

本ブログは、Azure で VM イメージを外部テナントへ共有する方法を紹介する記事の後編となります。

共有するための VM イメージの準備については、前編 ( イメージ準備編 ) はこちら を参照ください。

2通りの方法を紹介

本ブログでは、共有イメージギャラリーを外部のテナントへ共有する方法として、以下の 2 通りの方法を紹介します。

  1. 共有イメージギャラリーとアプリ登録を利用する方法 ( Azure のドキュメントで紹介されている方法 )
  2. Azure Lighthouse を利用する方法

本ブログでは、メリットとデメリットを整理しながら、両手法の手順をご紹介します。なお、共有するイメージは Linux ( centos ) ベースのイメージを前提としています。また、イメージを共有する側をテナント1とし、イメージを共有される側 ( =利用する側 ) をテナント2とします。

共有方法1：アプリ登録を利用する方法 ( Azure のドキュメントで紹介されている方法 )

Azure のドキュメントでは、異なるテナントとイメージを共有する方法として以下のイメージギャラリーとアプリ登録を利用する方法 ( Azure テナント間でギャラリー VM イメージを共有する – Linux の例 ) が紹介されています。

本手順で紹介されている方法は、テナント1 ( イメージを共有する側 ) では相手のテナントIDを知る必要がないメリットがあるものの、共有された側で利用する際に Azure CLI での操作など、手順が複雑になる点がデメリットとしてあげられます。

  • メリット
    • テナント1 ( イメージを共有する側 ) では相手のテナントIDを知る必要がない。
    • テナント1側での共有操作は、Azure Portal から実施できる。
  • デメリット
    • テナント2 ( イメージを共有される側 ( =利用する側 ) ) で利用する際に、コマンドラインからの操作 ( Azure CLIなど ) がh必要となる。

なお、本手法と同じパターンの共有方法として、単純に RBAC で共有する方法も紹介されています。アプリ登録を作成する必要がないところは手順が変わりますが、利用する側で手順は同様となりますが、事前に共有相手のメールアドレスなどの情報が必要となります。詳細はドキュメント ( ポータルを使用して共有イメージ ギャラリーを作成する – ギャラリーを共有する ) などを参照ください。

共有する側 ( テナント1 ) での手順

  • Azure Portal で「アプリの登録」-「新規登録」を選択します。
  • 概要ページの「アプリケーション (クライアント) ID」をコピーし、後で使用するために保存します。
  • 「証明書とシークレット」を選択してから、「新しいクライアントシークレット」を選択します。「説明」に適当な値、「有効期限」を適当な設定値にして「追加」を選択します。
  • シークレットの値をコピーし保存しておきます。
  • 対象の共有イメージギャラリーに対し、アプリの権限を付与します。
    • 「アクセス制御 (IAM)」を選択したら、「ロール割り当ての追加」で「追加」を選択します。
    • 「ロール] で 「閲覧者」を選択します。
    • 「アクセスの割り当て先」で「Azure AD のユーザー、グループ、サービス プリンシパル」のままにします。
    • 「選択」に作成したアプリの名称を入力し、一覧に表示されたら選択します。 完了したら、「保存」を選択します。
  • イメージの共有相手へ共有する情報として以下を保存しておきます。
    • テナント1のテナントID ( 共有する側のテナントID )
    • 共有イメージギャラリーのイメージバージョンのリソースID
      • テナント1のイメージが作成されているサブスクリプションID、リソースグループ名、イメージ定義、バージョンが含まれます。
    • アプリケーションID
    • クライアントシークレット
    • アプリの名称

利用する側 ( テナント2 ) での手順

  • 以下の URL にブラウザからアクセスし、テナント2 のユーザーでサインインします。
    • <Tenant 2 ID>：利用する側のテナントID
    • <Application (client) ID>：共有されるアプリケーションID
https://login.microsoftonline.com/&lt;Tenant 2 ID&gt;/oauth2/authorize?client_id=&lt;Application (client) ID&gt;&amp;response_type=code&amp;redirect_uri=https%3A%2F%2Fwww.microsoft.com%2F
  • サインインの際に、アクセス許可を確認する画面が表示されます。
  • 「承諾」の後に「No reply address is registered for the application.」のエラーが出る場合がありますが、無視して問題ありません。(アプリ作成時にURLを入力していない場合)
  • 任意のリソースグループに対し、追加したアプリケーションの「共同作成者」としてのアクセス権を付与します。



  • Azure CLI で、指定された情報にてテナント1 にサインインします。
az account clear
  az login --service-principal -u '&lt;Application (client) ID&gt;' -p '&lt;Secret&gt;' --tenant '&lt;Tenant 1 ID&gt;'
  az account get-access-token
  • Azure CLI で、指定された情報にてテナント2 にサインインします。
az login --service-principal -u '&lt;Application (client) ID&gt;' -p '&lt;Secret&gt;' --tenant '&lt;Tenant 2 ID&gt;'
  az account get-access-token
  • 以下のコマンドで VM を作成します。
    • <image version resource Id>：共有イメージギャラリーで作成したバージョンのリソースID
    • myResourceGroup：VM 作成先のリソースグループ ( 先に作成しておく )
    • myVM：作成する VM 名
    • az vm create コマンドには多くのオプションを指定可能で、インスタンスサイズやネットワーク関連などはオプションで指定します ( 参考：az vm create )。
az vm create \
      --resource-group myResourceGroup \
      --name myVM \
      --image "&lt;image version resource Id&gt;" \
      --admin-username azureuser \
      --generate-ssh-keys
  • VM が以下のように作成されます。

共有方法2：Azure Lighthouse を利用する方法

上記の共有方法1では、手順を示したように、利用する側での手順が若干複雑になります。現時点では Azure CLI からの操作が必須となることもハードルとなるかもしれません。

これから紹介する共有方法2には以下の特徴があり、利用する側での操作が Azure Portal のみで済むということが特徴です。

  • メリット
    • テナント2 ( イメージを共有される側 ( =利用する側 ) ) で利用する際に、Azure Portal からの操作で VM イメージを選択できる。
  • デメリット
    • テナント1 ( イメージを共有する側 ) では共有相手 ( テナント2 ) のテナントIDを知る必要がある。
    • テナント1 側での共有操作は、Azure CLI からの操作が必要となる。

共有手順2では、Azure Lighthouse の機能を利用します。Azure Lighthouse はテナントの管理などを委任するための機能で、異なるテナントのユーザーなどへ管理権限などを付与することができます ( 参考：Azure Lighthouse ドキュメント )。

共有する側 ( テナント1 ) での手順

  • 事前手順：共有手順2 では、事前に利用する側 ( テナント2 ) の以下の情報を共有してもらいます。
    • テナント2 のテナントID
    • 操作者のオブジェクトID ( ユーザー、グループ、サービスプリンシパルなど )

Azure Lighthouse での権限付与設定は、設定ファイルの準備と Azure CLI での実行が必要です。手順は Azure Lighthouse への顧客のオンボード に記載されている手順に従います。

  • パラメータファイルの修正。Azure Resource Manager テンプレートの作成 の、リソースグループを共有する手順に従い、リソースグループへ権限付与します。
    • 「使用する Azure Resource Manager テンプレート」はそのまま使用します。
    • 「変更するパラメーター ファイル」のうち以下を修正します。
      • mspOfferName.value: オファー名 ( Azure Portalで表示される )
      • rgName: リソースグループの名称
      • mspOfferDescription: オファーの説明
      • managedByTenantId.value ( “ ) : テナント2のテナントID
      • authorizations.value.principalId ( 2か所 ): 操作者のオブジェクトID
      • authorizations.value.principalIdDisplayName ( 2か所 ) : 表示名
      • ( roleDefinitionIdについて ) ：参考：Azure 組み込みロール
{
      "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
      "contentVersion": "1.0.0.0",
      "parameters": {
          "mspOfferName": {
              "value": "xxxxxx shared image"
          },
          "rgName": {
              "value": "test-rg"
          },
          "mspOfferDescription": {
              "value": "xxxxxx shared image"
          },
          "managedByTenantId": {
              "value": "&lt;insert managing tenant id&gt;"
          },
          "authorizations": {
              "value": [
                  { 
                      "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", 
                      "roleDefinitionId": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
                      "principalIdDisplayName": "PIM_Group" 
                  }, 
                  { 
                      "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", 
                      "roleDefinitionId": "91c1777a-f3dc-4fae-b103-61d183457e46",
                      "principalIdDisplayName": "PIM_Group" 
                  }
              ]
          }
      }
  }
  • Azure Resource Manager テンプレートと、修正したパラメータファイルを元に、Azure Lighthouse の設定をデプロイします。
    • --name: デプロイ名 ( 任意の名前 )
    • --location japaneast: リージョン名
    • --template-file template.json: テンプレートファイルの名称 ( Azure のドキュメントで提供されているものをダウンロードしてそのまま使用 )
    • --parameters param.json: 前手順で修正したファイルの名称
    • --subscription: テナント1のサブスクリプションID
az deployment create --name &lt;Name of deploy&gt; --location japaneast --template-file template.json --parameters param.json --verbose --subscription &lt;Tenant 1 Subscription ID&gt;
  • デプロイを確認します
    • Azure Portal で、Azure Lighthouse の「サービス プロバイダーのオファー」にオファー名の付いた内容が表示されることを確認します ( デプロイが完了してから Azure Portal に更新が反映されるまで数分かかる場合があります )。

利用する側 ( テナント2 ) での手順

利用する側では、自分のテナントとテナント1 のリソースの双方を表示できる状態にし、イメージを選択して VM を作成します。

  • Azure Portal 右上のアカウント情報から、「ディレクトリの切り替え」を選択し、「すべてのディレクトリ」、「すべてのサブスクリプション」が表示される状態にします。
  • 通常の VM 作成同様に、「Virtual Machines」から「追加」-「仮想マシン」を選択します。
  • 「イメージ」で「すべてのパブリックおよびプライベートイメージを参照する」を選択し、「マイアイテム」-「共有イメージ」を選択すると、参照できるようになったイメージが表示されます。
  • イメージの選択後は、通常の VM 作成と同じ手順で VM を作成することが可能です。なお、テナント2側で VM 作成後は、Azure Lighthouse での委任の設定は削除してかまいません ( テナント1側の操作で削除可能です )。

まとめ

本ブログで紹介した共有方法は、以下のようなメリットデメリットがあるということになります。不特定多数にイメージを共有したい場合は、アプリ登録または Azure Marketplace を利用することになりますが、Azure Marketplace の場合には、登録にあたって審査等があると思われます。アプリ登録での方法は、 ( 現時点では ) 利用する側で Azure CLI での操作が必要になるというのがデメリットとなり、ユーザーによってはハードルが高い操作となるかもしれません。

比較ポイントアプリ登録RBACAzure LighthouseAzure Marketplace ( 想像 )
テナント1 での操作 ( 共有設定時 )Azure PortalAzur PortalAure CLIAzure Portal
テナント2 での操作 ( イメージ利用時 )Aure CLIAure CLIAzure PortalAzure Portal
テナント1はテナント2の情報を知っている必要があるか不要共有相手のアカウントのメールアドレステナント2 のテナントID と操作者のオブジェクトID不要

なお、Azure Marketplace への登録については未経験のため、テナント1 側の操作については想像です！

おわりに、Azure Marketplace へ登録すれば解決？

本ブログでは、異なるテナントへの VM イメージ共有方法として、2通りの手段を紹介しました。双方にメリット/デメリットがあるため、現状だと目的に応じて使い分ける形になると思います。

一方、より不特定多数に対して簡単にイメージを共有するには、Azure Marketplace へイメージを登録ことになると思われます。現時点では Azure Marketplace への登録はトライできておりませんが、今後実施でき次第、手順などをまたブログへ公開できればと考えています。

開発メンバー募集中デス。


インサイトテクノロジーにご興味を持たれたエンジニアの方、ぜひご連絡をお待ちしております♪
インサイトテクノロジー 採用情報

関連最新記事

TOP – インサイトブログ – 開発 – Azure で VM イメージを外部へ共有するには ～ 後編：イメージ共有編 ～

Recruit 採用情報

Contact お問い合わせ

  購入済みの製品サポートはこちら

製品情報

製品

自社開発製品群

製品一覧

プロフェッショナルサービス

製品サポート

事例紹介

資料ダウンロード

ニュース

イベント・セミナー

ブログ

企業情報

採用情報  

お問い合わせ

キーワードから探す

業界から探す