みち草

Azure中心にまとめる技術情報ブログ

Shared Image Galleryで異なるAzure ADテナントのイメージからVMをデプロイする

はじめに

今回はAzureのShared Image Galleryを利用して、あるAzure ADテナントで作成・登録したイメージ(スナップショット)を使って、別のAzure ADテナントにVMをデプロイしてみたので、方法を紹介します。

目次

Shared Image Gallery概要

Shared Image Galleryは、2019年5月に一般公開されたサービスです。
https://azure.microsoft.com/ja-jp/updates/shared-image-gallery-generally-available/

共通の設定を導入したイメージを作成および登録することで、別サブスクリプションや、別のAzure ADテナント内のユーザーがそのイメージを利用してVMをデプロイできます。
加えて、イメージ更新時のバージョン管理までできちゃいます。

一般化された(sysprep済み)イメージ、特殊化された(sysprepなし)イメージのどちらにも対応していますが、投稿時点(2019年12月)では、特殊化されたイメージはプレビュー機能です。

今回はプレビューである、特殊化されたイメージ(OSディスクのスナップショット)を別テナントでデプロイします。
プレビューの制限として、特殊化されたイメージのデプロイはPowerShellかCLIのみ可能(ポータル不可)のため、PowerShellスクリプトでデプロイします。

参考は以下です。

Azure Shared Image Gallery | Microsoft Docs

Azure のテナント間でギャラリー イメージを共有する | Microsoft Docs

構成イメージ

イメージは以下です。
以降では、ギャラリー側をテナント1(サブスクリプション1)、デプロイ側をテナント2(サブスクリプション2)として表記します。

ギャラリー1

  1. サブスクリプション1で、OSディスクのスナップショットを作成します
  2. サブスクリプション1で、イメージ(スナップショット)をShared Image Galleryに登録します。
    ※正確にはShared Image Gallery内にイメージ定義を作成、イメージバージョンとして登録ですが、図中では省略します。
  3. テナント2のユーザーをテナント1に招待します。
  4. 招待したユーザーに対して、ギャラリーの読み取り権限を付与します。
  5. スクリプトを用いて、サブスクリプション1のイメージを基に、サブスクリプション2にVMをデプロイします。

sysprep無しのイメージなので、VMがテナントを移動したような動きになります。早速やっていきます。

環境構築

VMイメージ(スナップショット)作成

MSドキュメント内の言葉を借りて「特殊化されたイメージ」記載していますが、つまりはOSディスクのスナップショットを指しています。

VMを停止して、OSディスクのスナップショットを作成します。

ギャラリー2

データディスクを利用している場合は、併せてスナップショットを取得しておきます。

Shared Image Gallery準備

取得したスナップショットを登録するため、Shared Image Gallery(共有イメージギャラリー)を作成します。

ギャラリー3

ギャラリーを作成したら、そこに「イメージ定義」を追加します。

ギャラリー4

項目やタブがたくさんありますが、単に使うだけなら[基本]タブだけ埋めればOKです。
今回は特殊化されたイメージのため[特殊化]を指定します。

ギャラリー5

最後に、「バージョンの追加」を行います。

ギャラリー6

ここで、[OSディスクのスナップショット]として最初に作成したスナップショットを選択します。
データディスクがある場合には、LUNと併せて[データディスクのスナップショット]に指定します。

ギャラリー7

10分ほど待ちイメージバージョンが作成されたら、Shared Image Galleryの準備は完了です。

ギャラリー8

招待&権限割り当て

イメージを使わせたい別テナントのユーザーに対して、作成したギャラリーの読み取り権限(閲覧者ロール)を付与します。

別テナントのユーザーに権限を付与するには、以下を参考に対象ユーザーを招待しておきます。

クイック スタート:Azure portal でゲスト ユーザーを追加する - Azure AD | Microsoft Docs

招待後、ギャラリーの[アクセス制御]-[追加]-[ロールの割り当ての追加]を開きます。

ギャラリー9

[役割]は[閲覧者]を指定し、[選択]に外部テナントのユーザー名を入力します。

ギャラリー10

表示されたユーザーをクリックし保存します。
[ロールの割り当て]タブを見たときに、閲覧者として追加されていれば準備はOKです。

ギャラリー11

スクリプト準備

特殊化イメージの利用はプレビューでありPowerShellまたはCLIでのデプロイのみのため、以下のPowerShellスクリプトを用意しました。

$Subscription = "サブスクリプションID"
$ResourceGroup = "リソースグループ名"
$Location = "リージョン名"
$VNetName = "VNet名"
$VmName = "VM名"
$NicName = $VmName + "-NIC"
$GIpName = $VmName + "-IP"
$Image = "イメージバージョンのリソースID"

#サブスクリプションにログイン
Connect-AzAccount
Select-AzSubscription -Subscription $Subscription

# パブリックIP作成
$GIp = New-AzPublicIpAddress -ResourceGroupName $ResourceGroup -AllocationMethod Dynamic -Location $Location -Name $GIpName

# VNet取得
$VNet = Get-AzVirtualNetwork -ResourceGroupName $ResourceGroup -Name $VNetName

# 指定サブネットのNIC作成
$Nic = New-AzNetworkInterface -Name $NicName -ResourceGroupName $ResourceGroup -Location $Location `
  -SubnetId $VNet.Subnets[0].Id -PublicIpAddressId $GIP.Id

# ギャラリーイメージを基にVMデプロイ用Config作成
$VmConfig = New-AzVMConfig -VMName $VmName -VMSize Standard_A1_v2 | `
  Set-AzVMSourceImage -Id $Image | `
  Add-AzVMNetworkInterface -Id $Nic.Id

# VMデプロイ
New-AzVM -ResourceGroupName $ResourceGroup -Location $Location -VM $VmConfig -DisableBginfoExtension

スクリプトは以下のことを行います。

  1. 指定サブスクリプションにログイン
  2. パブリックIP作成
  3. 指定VNetの先頭サブネットに接続するネットワークインターフェース作成
  4. 別テナントのギャラリーイメージを基に、VMデプロイ用のConfig作成(サイズはA1v2)
  5. Configを基にVMデプロイ

上部の変数に任意の値を指定すればOKですが、$Imageはサブスクリプション1側で取得する値、それ以外はサブスクリプション2側の値になります。

また、$Imageには「イメージバージョンの」リソースIDを指定してください。[プロパティ]からコピーできます。

ギャラリー12

VMデプロイ

準備ができたらスクリプトを実行し、ギャラリーの読み取り権限を付与したユーザーでログインすれば、テナント1のイメージを利用したVMがデプロイされます。

スクリプト実行結果

ギャラリー13

デプロイされたVMは、ソースが「共有イメージ」になります。

ギャラリー14

以上で、Shared Image Galleryを用いて、異なるAzure ADテナントのイメージからVMをデプロイすることができました。

おわりに

一般リリースされれば特殊化イメージでもポータルでデプロイ可能になるとは思いますが、VMをテナント間移動させる方法の1つとして試したため、せっかくならと記事にしました。

Azureでテナントを超えるってなかなか面倒なのですが、そもそも共有する用のサービスなのでやりやすかったです。

ギャラリーを使えば別サブスクリプションへのカスタムイメージの持ち込みも可能であるため、日本語化&社内で定められた設定実施済みのテンプレートを様々なサブスクリプションで利用することなんかもでき、いろいろ使い道のあるサービスではないかと思います。

ユーザーにあまり権限をつけたくない、という方でも安心な読み取り権限だけOKなのもよいです。

気が向いたら一般化イメージでも試してみたいと思います。

Azure BastionにNSGを設定する

はじめに

以前、別記事でBastionについて記載しましたが、その際はサブネット上のBastion自体にNSGを設定していませんでした。

踏み台サーバがPaaS化!Azure Bastionを試す! - みち草

最近になって試してみたところ、BastionのNSGはシステム用のルールを許可する必要があるため、自分のグローバルIPアドレスを許可するだけでは足りませんでした。

本記事では、BastionにNSGを設定する際の必須ルールを紹介します。

目次

BastionへのNSG設定

Azure BastionとNSG

Bastionは仮想ネットワーク内に専用サブネット(AzureBastionSubnet)を作成してデプロイするため、そのサブネットにNSGを適用することでBastionへアクセス可能なIPアドレスを制御でき、より安全な接続が可能です。

ただし、マネージドなPaaSサービスであるため、動作させるために必ず許可しなければならない通信があります。

それについて、以下の公式ドキュメントに記載があります。
(セッション監視については「セッションの監視と管理」ページに記載あり)

Azure Bastion で VM と NSG を使用する | Microsoft Docs

これを満たさないNSGをAzureBastionSubnetに割り当てようとすると、画像のように「Bastionに必要なルールが足らん」とエラーが出てしまいます。

BastionNSG1

ではどんなルールが必要なのか、次にまとめます。

Bastion用NSGの必須ルールと適用

NSGをデフォルトの状態で使う場合は送信が全許可されていますが、その場合でも次の受信2つ、送信2つで合計4つのルールが絶対に必要です。

受信ルール

(1) Bastion制御用の通信許可ルール
 "GatewayManager"タグからの、ポート"443"通信を許可します。

(2) セッション監視機能用の通信許可ルール
 "GatewayManager"タグからの、ポート"4443"通信を許可します。

これらは同じ発信元からの許可ルールなので、以下のように1ルールにまとめてもOKです。

BastionNSG2

送信ルール(デフォルトNSGでも必要!)

(1) Bastion機能用の通信許可ルール
 "AzureCloud"タグへの、ポート"443"通信を許可します。
 ※記事作成時点ではリージョン付タグ(AzureCloud.xxx)は非サポート

BastionNSG3

(2) 仮想ネットワークへの通信許可ルール
 "VirtualNetwork"への、ポート"3389/22"通信を許可します。

BastionNSG4

これら4つ(まとめると3ルール)を許可することで、ようやくAzureBastionSubnetにNSGを割り当てることが可能です。

BastionNSG5

BastionNSG6

これでAzure BastionにNSGを設定することができました。
あとは自宅のIPでも会社のIPでも、好きなものを許可しましょう。

ちなみに、利用者のグローバルIPに対しては443の通信を許可してくださいね。

接続先VM用NSGにて必要なルール

おまけとして、VM側のNSGで場合により必要なルールは以下です。
デフォルトのNSGであれば追加不要ですが、必要最低限のみ許可などポリシーが厳しい場合には必要になるでしょう。

受信ルール

(1) AzureBastionSubnetからの受信ルール
 "AzureBastionSubnetのIPアドレスレンジ"からの、ポート"3389/22"通信を許可します。

BastionNSG7

おわりに

今回は、Azure Bastionにて、許可が必須なNSGルールを紹介しました。

サービスの使用に必要な通信でも、明示的な許可が必要なものと不要なもの(内部で許可される)がありなかなかややこしいです。
それについてもそのうちまとめたいと思います。

その点Bastionは適さないNSG割り当てを拒否してくれるので、まだ親切ですね。

新規Azure ADを作成したらMFAを強制された

はじめに

今回はAzure ADの話です。

先日、Azure ADを新規で作成する機会がありましたが、その際にMFA(多要素認証)を強制されました。

備忘も兼ねて原因と解除方法を紹介します。

目次

MFAの強制

起きたこと

先日、検証環境を用意するため、クレジットカードを用いてサブスクリプションを作成しました。

MFA1

その後、新規にAzure ADを作成し、既定のディレクトリから新規Azure ADへディレクトリ変更を行いました。

MFA2

新規Azure ADには社用組織アカウントを招待しており、それでログインしサブスクリプションを使おうとしたところ、MFAの設定画面が表示されました。
社用アカウントは元々MFA必須のため、このときはそれが原因かと思い特に気にしていませんでした。

MFA3

その後、検証用に新規に作成した組織アカウントすべてでも同様にMFA設定を求められ、さすがに何かしらの力が働いている...と思い調べたところ今回の設定に至りました。

MFA4

原因

原因はこれ、Azure ADのセキュリティデフォルトでした。

Azure Active Directory security defaults | Microsoft Docs

以下は上記サイトの抜粋です。

Microsoft では、誰もがセキュリティ既定値を利用できるようにしています。 目標は、すべての組織が追加の費用なしで基本レベルのセキュリティを確実に有効にできるようにすることです。 セキュリティ既定値は、Azure portal で有効にします。
---中略---
テナント内のすべてのユーザーは、Azure Multi-Factor Authentication サービスのフォームを使用して多要素認証 (MFA) に登録する必要があります。

ということで、近頃のAzure ADはセキュリティ強化のための設定が既定で有効化されており、それによりMFAがテナント内の全ユーザーに強制されます。

解除方法

今回のような単なる検証用途では都度対応するのが面倒である、そんな方のための解除方法を記します。

Azureポータルにて、[Azure Active Directory]の[プロパティ]を開きます。
一番下にある青文字の[セキュリティ既定値の管理]をクリックします。
セキュリティ既定値の設定が面が開くので[いいえ]を選びます。

MFA5

理由を問われるため任意に指定し[保存]をクリックします。

MFA6

通知が表示されれば変更完了です。

MFA7

これで解除完了です。

おわりに

様々な脅威にあふれる昨今、追加の料金なく、すべてのユーザーに対してMFAを設定しセキュリティを強化できるのは結構すごいことではないでしょうか。

今回は検証環境のため無効としましたが、実環境の場合には、有効としたままの利用も考慮する価値がある設定だと感じます。

ただ、私はこの設定の存在を知らずにいきなりMFAを求められ驚いたので、まずは同じような方に要否関係なく知ってもらえればいいなと思います。

Azure VM(ARM)にBGInfo拡張機能をインストールする

はじめに

今回は、Azure VMにBGInfo拡張機能をインストールする方法を紹介します。

クラシック(ASM)VMではデプロイ時の他の拡張機能と同様に選択してインストール可能でしたが、 ARMでは拡張機能画面に表示されないため、インストール方法を紹介します。

目次

BGInfoインストール

BGInfo概要

BGInfoとは、デスクトップにホスト名やメモリサイズ、IPアドレスなどを表示させることが可能なツールです。

これをインストールすることで、多数のマシンにログインしている場合や多重RDP接続をしている場合に、 常に背景にシステム情報が表示されるため、どのマシンを操作しているかわかりやすくなります。

Azure VMでもクラシックの頃から利用でき、デプロイ時にチェックを入れるだけでインストールすることが可能でした。

ARMでは、以下の「拡張機能」画面にBGInfoが表示されませんが、後述するPowerShellコマンドを利用することでインストールが可能です。

BGInfo1

インストール用コマンド

ARM VMにBGInfoをインストールするには、以下のコマンドを実行します。

Set-AzVMBgInfoExtension -ResourceGroupName "<リソースグループ名>" -VMName "<VM名>" -Name "BGInfoExtension"

Nameパラメータは、ポータルの「拡張機能」画面で表示される名前なので、任意の名前でOKです。 リソースグループ、VMを正しく指定しましょう。

インストールおよび確認

Windows Server2016のVMにインストールしてみます。 VMが起動状態でなければ、拡張機能をインストールできないため起動しておきます。

BGInfo2

PowerShellでサブスクリプションにログインし、先ほどのコマンドを実行します。

BGInfo3

30秒ほど待ち、以下の結果となればインストール完了です。

BGInfo4

VMの拡張機能画面では、状態が"Provisioning succeeded"となればOKです。 コマンド中に指定した名前で表示されています。

BGInfo5

仮想マシンにログインすると、デスクトップの右上にシステム情報が表示されています。

BGInfo6

これで、ARM VMへのBGInfo拡張機能のインストールは完了です。

おわりに

ARMでGUIに表示されなくなった理由はわかりませんが、PowerShellでインストール可能なので、必要な方は試してみてください。

個人的にはPaaSの踏み台、Bastionでログインすれば多重RDPにならないので不要か?とは思いつつ、 あったらあったで安心なのかなぁとも思うので微妙なところ。。。

Bastionについては別記事で記載しているため、良ければ見てみてください。

踏み台サーバがPaaS化!Azure Bastionを試す! - みち草

AzureポリシーでNSGの設定値を制限する

はじめに

今回は、Azureポリシーを用いてリソースの設定値を制限する方法の紹介です。

以前、AutomationにPowerShellスクリプトを登録して特定のNSGルールを検出し、SendGridでメール通知する、という記事を投稿しました。

Azure AutomationとSendGridで発信元AnyのNSGルールを検出してメール通知してみた - みち草

これだと結局メールを確認する必要があり面倒で、NSGの作成/変更を検出して何とかしたいなぁと調べたところ、 Azureポリシーで特定の設定値を禁止できそうだったため試してみました。

「ソースIPアドレスがAnyのNSGルールは作成不可」というルールを設定します。

目次

Azureポリシー

概要

Azureポリシーは、リソースに対して名前や設定値のルールを与えることができるサービスです。 例として、[ストレージアカウントのSKUはLRSのみとする]、[東日本リージョンのみデプロイ可能]、[タグとして○○を必須とする]などが指定可能であり、それに違反するリソースをデプロイできないよう制御できます。

ポリシーは適用先としてサブスクリプションかリソースグループを選ぶことが可能なため、全体としての制御や、特定のリソースグループ内のみの制御など用途に合わせて利用します。

組み込みで用意されているルールもありますが、今回は該当するものがないため、JSONを記述して作成しています。

以下のサイトを参考にしました。

Technical Deep Dive: Azure Policy - Deny inbound RDP from the internet

ポリシーの内容

今回使用するポリシーはこれです。

{
  "mode": "All",
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Network/networkSecurityGroups/securityRules"
          },
          {
            "field": "Microsoft.Network/networkSecurityGroups/securityRules/access",
            "equals": "Allow"
          },
          {
            "field": "Microsoft.Network/networkSecurityGroups/securityRules/direction",
            "equals": "Inbound"
          },
          {
            "field": "Microsoft.Network/networkSecurityGroups/securityRules/sourceAddressPrefix",
             "in": [
                  "*",
                  "Internet"
              ]
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    },
  "parameters": {
  }
}

policyRuleブロック内に、JSONで条件を記述します。 allOfがand、anyOfがorとしてブロック構造で条件分岐を記述するので、なかなか書きづらいです。

条件と処理部分を日本語で書くと、「"リソースの種類がNSGのルール" かつ "アクセスを許可するルール" かつ "受信ルール" かつ "ソースアドレスが *(Any) または Internetタグ"ならば、拒否する」です。

これで不特定なIPアドレスからの接続を許可するNSGルールを禁止するポリシーとして機能します。

パラメータとして指定したポート番号を使用するルールは拒否、など も可能ですが、ここでは利用していません。

公式ドキュメントにサンプルが紹介されています。

ポリシーのサンプルのインデックス - Azure Policy | Microsoft Docs

ポリシーの定義、割り当て

実際にポリシーを作成し適用します。まずは、適用するポリシー(ルール)を定義します。

ポリシー1

[定義の場所]ではサブスクリプションを指定します。 その他は任意に指定します。

ポリシー2

ポリシー定義に先ほどのJSONを貼り付け、保存します。

ポリシー3

[種類]を"カスタム"に変更すると自作ポリシーのみ表示されるため、先ほど作成したポリシーの名前をクリックします。

ポリシー4

[割り当て]をクリックします。

ポリシー5

[スコープ]や[除外]の欄を用いることで、サブスクリプションの中の特定のリソースグループまたはリソースにのみ ポリシーを適用することや、一部のリソースグループやリソースを適用対象外とすることが可能です。

今回はサブスクリプション全体に適用するのでこのままです。 パラメータがあるポリシーを定義した場合は、パラメータタブにて指定することができます。

ポリシー6

修復タブでは、ポリシー用のマネージドIDの作成を指定できます。 ポリシーの作成の仕方によっては、ルールに合致した際に自動設定や自動修正が可能であり、それ用のIDです。 これはそのうち試してみたいですが、今回はそのままにして割り当てを実行。

ポリシー7

サービスIDについては以前にちょこっと書いたのでそれ参照。

AzureサービスにIDを与える!マネージドID - みち草

これでポリシーの定義と割り当ては完了です。

テスト

早速、適用したポリシーの動作をテストします。

送信元がAnyのNSGルールを追加してみます。

ポリシー8

すると。。。

ルールの作成時にエラーが表示され、「ポリシーにより許可されませんでした」とあります。

Azureポリシーを用いて、ルールに合致した設定値を拒否することができました。

ポリシー9

もちろん、ソースIPアドレスを指定したルールであれば作成可能です。

ポリシー準拠状況の確認

概要からポリシー名をクリックすると、そのポリシーの適用範囲に存在するリソースについて、 ポリシーの準拠状況や、準拠していないリソース、拒否されたイベント発生数などを確認することができます。

※割り当て後、状況取得にはある程度時間がかかります。

ポリシー10

以下は別のポリシーのキャプチャですが、時間が経つとポリシーの準拠していないリソースがどのくらいあるのか表示してくれます。

ポリシー11

イベントを発生させたユーザーもわかるので、誰が設定を行おうとしたか、ばっちりわかります。

ポリシー12

料金

Azureポリシーの利用料金は発生しないため、好きなだけ使えます。

価格 - Azure Policy | Microsoft Azure

気になること

ルールに合致した設定を拒否できるAzureポリシーですが、ちょっと気になる箇所があります。

それは、ユーザーが自分で設定した際は拒否してくれるのですが、システム的に設定される場合は拒否されない、という点です。

例として試したのは、VM作成時の以下の設定です。

ポリシー13

このチェック用いると、VMデプロイ時のインターフェースに割り当てられるNSGに対して自動でルールを追加してくれます。 ただし、ソースIPアドレスががAnyなのです。

今回のポリシーを適用していても、拒否されずにデプロイされてしまいます。

まぁ、以前は警告なくAny許可でしたが、最近は「すべてのIPアドレスからアクセス可能になります」と注意を明記してくれるだけマシになりました。 システム的に防ぎたいところですがダメそうです。。。

おわりに

今回は、Azureポリシーでリソースの設定値を制限する、ということを紹介しました。

組み込みのポリシーで済むようであればそれだけで、費用なく設定が可能です。 もし求めるものがない場合は作成するしかありませんが、記事中で紹介したサンプルページもあるため、それを参考にするのが良いかと思います。

環境全てをポリシーで制御しようと思うとひたすらJSON記述になり大変ですが、これは絶対使わせない!という設定を制御するにはよいかと思います。

プロキシやファイアウォールでAzureポータルのURLを許可する

はじめに

いつの間にか、Azureポータルを使うためにプロキシやFWで許可が必要なFQDNが公式に出ていたため、その紹介です。

目次

許可すべきURL

Azureポータルを利用するために許可が必要なFQDNはこれらです。

以下に対して、80/443ポートでの通信が必要です。

*.aadcdn.microsoftonline-p.com
*.aka.ms
*.applicationinsights.io
*.azure.com
*.azure.net
*.azureafd.net
*.azure-api.net
*.azuredatalakestore.net
*.azureedge.net
*.loganalytics.io
*.microsoft.com
*.microsoftonline.com
*.microsoftonline-p.com
*.msauth.net
*.msftauth.net
*.trafficmanager.net
*.visualstudio.com
*.windows.net
*.windows-int.net

上記は一般用であり、Governmentリージョン、中国リージョンではそれぞれ許可が必要なFQDNが異なるようです。詳細は以下のサイトを参照ください。

Azure portal の URL をセーフリストに追加する | Microsoft Docs

これで、アクセスを制限している環境でもAzureポータルが使えそうですね。

ちょっと心配なこと

数年前、AzureのIaaS環境を構築した際、「社内からインターネットへ出る際はプロキシで制限をかけている。Azureを使用するために許可が必要なURL、FQDNを教えてほしい。」と言われたことがあります。 その頃は上記の公式情報がなくサポートに聞いて、それをお客さんに設定してもらい構築作業に臨みました。

すると、ポータル自体は表示されており問題ないように見えるのですが、当時は選択制だった[ストレージの暗号化を有効にする]をクリックすると、 実は別のURLに飛ぶようで、そこが許可されておらずエラーが出て有効化できない、という問題で手間取ったことがあります。

という具合に、ポータル内の操作によって別のURLが必要なことが多々あるようで、同じようなことにならないといいなーという心配があります。

足りないものがあれば今後更新されていくとは思いますし、そもそも公式なので信じるしかないですが...(-"-)

おわりに

昔引っかかったことを思い出しましたが、その頃から考えると、公式にまとめて頂けるのは大変ありがたいです。

新しいサービスが出た際にはFQDNも追加される可能性があるため、利用の際は適度にチェックした方がよさそうです。

Azureポータルを前のメニューに戻す

はじめに

これまで結構キッチリ書いてましたが、今回は軽めの投稿です。

先日、Azureポータルの表示方法やアイコンが変わったので、以前の表示方法への戻し方紹介です。

目次

新しいポータル

以前は左端のメニューが常時表示されていましたが、左上の3本線をクリックすることで表示されるように変更されました。 ハンバーガーメニューと言うらしいです。

ポータルの表示変更1

ポータルの表示変更2

メニューにマウスカーソルを乗せておくと、最近使用したリソースなどが表示されます。

ポータルの表示変更3

以前の表示に戻す

以前のような常時表示に戻すには、左上の歯車マークをクリックし、ポータルの設定を開きます。

「Chose your default mode for the portal monu」を[ポップアップ]から[ドッキング]に変更します。

ポータルの表示変更4

これで、以前のように左端のメニューが表示されます。 [>>]をクリックすれば広がります。

ポータルの表示変更5

ポータルの表示変更6

おわりに

今回は小ネタ的にポータルの表示変更について記載しました。

戻すと言っても常時最小化されてしまうため完全に同じとはいきませんが、その辺りの変更は受け入れていくしかありませんね。

かく言う自分も手順書を作成しており焦りましたが、キャプチャ取得の直前に変更されたので助かりました...。

キッチリ書くことに拘り過ぎると続かなくなってしまいそうなので、今後はこのようなちょっとしたことも投稿したいなと思います。続けるの大事。

PaaSにプライベート接続!Azure Private Linkを試してみた

はじめに

9月17日、Azureの新サービスとしてAzure Private Linkがプレビュー公開されました。

Azure Private Link のプレビューを利用できるようになりました | Azure の更新情報 | Microsoft Azure

これを使うとなんと、AzureのVNetからはもちろん、VNetとVPN/ExpressRouteで接続したオンプレミス環境から、インターネットに出ないプライベート接続でPaaSサービスが使えてしまうんです!

こんな面白そうなもの試すしかない、ということで早速試してみました。

情報や手順は以下のサイトを参照しています。

What is Azure Private Link? | Microsoft Docs

目次

Private Link構成イメージ

繰り返しになりますが、Private LinkはAzure上のVNet、またはVNetにVPN/ER接続されたオンプレミス環境とPaaSをプライベート接続で繋ぐためのサービスです。

実際の構成イメージは以下のようになります。

f:id:kkkzk:20190919183541j:plain

PaaSへのプライベート接続を行うためには、VNet内へのプライベートエンドポイントの作成およびエンドポイントとPaaSとのリンクが必要です。

Azure VMまたはオンプレマシンがプライベートエンドポイントと通信することで、エンドポイントにリンクされたPaaSを使用することができます。 そのため、以下のどれかしらの方法にて、SQL DatabaseやストレージのFQDNが、エンドポイントのプライベートIPアドレスに名前解決される必要があります。

  • hostsファイルに記述する(テスト用のみ推奨)
  • プライベートDNSゾーンを使用する(楽だがプライベートDNSゾーンもプレビュー)
  • 環境内のDNSサーバーを使用する

なお、1つのVNet内に複数のエンドポイントを作成することや、VMと同じサブネットに作成することが可能です。AppGWのような専用サブネットは不要です。

Azure Private Linkでの接続~SQL Database編~

以下では実際にPrivate Linkを作成して、Azure VMからAzure SQL Databaseへのプライベート接続を行う流れを紹介します。

用意した環境

用意したのは以下の環境です。 すべて米国西部リージョンで作成しており、VNet、VM、NSGは作成済みです。

f:id:kkkzk:20190919184034j:plain

NSGでは、インターネット接続拒否の送信ルールを入れています。

f:id:kkkzk:20190919185519j:plain

プライベートエンドポイント作成

(1)[すべてのサービス]から[プライベートリンクセンター]を開く

f:id:kkkzk:20190919184229j:plain

(2)[サービスへのプライベート接続を開始する]の[開始]をクリック

f:id:kkkzk:20190919184245j:plain

(3)作成するエンドポイントのリソースグループや名前を指定して次へ

f:id:kkkzk:20190919184507j:plain

(4)接続対象のサービスを指定(ここではSQL Database)して次へ

「リソースIDまたはエイリアスを使って...」の方を選択することで、別サブスクリプションや別テナントのリソースに接続することが可能です。

f:id:kkkzk:20190919184523j:plain

(5)プライベートエンドポイントを作成するサブネット、プライベートDNS統合を指定して作成開始

f:id:kkkzk:20190919184741j:plain

(6)5分ほどでデプロイ完了

エンドポイント用ネットワークインターフェースが作成され、VNetに接続されていることがわかります。

f:id:kkkzk:20190919184808j:plain

f:id:kkkzk:20190919185349j:plain

(7)SQL Database側にもエンドポイント接続が設定される

f:id:kkkzk:20190919184828j:plain

接続テスト

(1)ログイン後にPowerShellを起動し、エンドポイントに関連付けたAzure SQL ServerのFQDNと、普段通りのAzure SQL ServerのFQDNをnslookupしてみる

関連付けたAzure SQL ServerのFQDN(kkplsqlserver.database.windows.net)がエンドポイントのプライベートIPアドレスに解決されていますが、何もしていない方のFQDNは当然ながらグローバルIPアドレスに解決されていることがわかります。

f:id:kkkzk:20190919185227j:plain

(2)いざManagement Studioで接続

f:id:kkkzk:20190919185408j:plain

接続成功!NSGを適用しているのでインターネットには出られませんが、PaaSが使えています。非常に簡単です!

f:id:kkkzk:20190919190513j:plain

NSGでの制御について

プライベートエンドポイントですが、NSGがサポートされていません。 詳しくは、NSGの適用されたサブネットにエンドポイントをデプロイすることはできますが、 宛先にエンドポイントのIPを指定した受信ルール、発信元にエンドポイントのIPを指定した送信ルールは、効力を発揮しません。

Azure VMからエンドポイントのIPへの送信を拒否することは可能なため、 VMからの発信を拒否するように送信ルールを書くことで制御は可能です。

プレビューなのでリリース時にはどうなるかわかりませんが、現状ではその仕様です。

価格

以下のサイトにあるとおり、エンドポイント自体とデータの送受信量に課金が発生します。 エンドポイント自体は1ヶ月(730時間)で410円くらいです。

価格 - Azure Private Link | Microsoft Azure

ただ、"Please note that above price is premium for Azure Private Link. Data Transfer pricing still applies to data transfer."という一文を見ると、通常のデータ送信料に加えてプライベートエンドポイントのデータ送受信料がかかる、ということのようです。

おわりに

これまでPaaSを使うにはインターネット経由(グローバルIPアドレス宛て)であることは避けられず、 それが原因でPaaSを使用しないということは多々ありました。

しかし、Private Linkを用いることでクラウド内とオンプレのどちらからでも、 宛先がプライベートIPかつインターネットに出さずにPaaSを使うことができるため、PaaSを使ってみよう、ということが増えるのではないかと思います。

設定自体も非常に簡単であり、せっかくクラウドを使うならなるべくPaaSを使いたいと思うので、 選択肢を増やせるPrivate Linkのリリースがリリースが今から楽しみです。

あとは、App Serviceに対応してくれれば...!