App Service に VNet 経由でストレージアカウントをマウントする際の注意点

はじめに

お世話になっております。App Service サポート担当の押田です。

App Service では組み込みの File Serversのほかに、独自のストレージアカウントをマウントすることが可能となっています。

App Service でローカル共有として Azure Storage をマウントする

この機能は Linux、Windows Container、Windows(コード)環境それぞれで制限や構成方法に違いがあります。

本記事では、Windows(コード)環境における、Azure Files のマウントについて記載します。

想定される構成

Azure Files をマウントするにあたって、Azure Files はできるだけセキュアに保つことは一般的な構成としてよく見受けられるものと存じます。

Azure Files の観点においては Private Endpoint を構成し、パブリックアクセスを無効にすることが可能となっています。

Azure Files ネットワーク エンドポイントの構成

以下のようにApp Service がストレージとして Azure Files をマウントする際に、VNet を経由してPrivate Endpoint を利用した接続にてマウントする方法、トラブルシューティング方法を紹介します。

Windows(コード)環境でマウントする際に Private Endpoint を利用する方法

手順としては基本的には下記ドキュメントに沿って実施ください。

App Service でローカル共有として Azure Storage をマウントする

WEBSITE_CONTENTOVERVNET を必ず設定する

注意点として、Windows(コード)環境で VNet 経由すなわち Private Endpoint を経由したマウントを行うためには、App Settings として WEBSITE_CONTENTOVERVNET に 1 を設定する必要があります。 ドキュメントの最下部に記載されているのみとなり、見落としがちなポイントとなります。

上記設定がない場合、Private Endpoint を利用したマウントが行われないことになります。

検証

App Service からは /mounts/myfiles というパスでストレージアカウントを利用するように構成します。

VNet 統合を用いない場合

まず、VNet 統合をしない状態、すなわち Private Endpoint を利用しない状態での App Service から Azure Files へのアクセスを見てみます。

VNET 統合未実施場合、下記の通り WEBSITE_PRIVATE_IP が未設定、 nameresolver の結果パブリックIPが取得できる状態です。 HTTPアクセスも疎通は可能です。（SAS未指定のためエラーとなっています。）

この時のストレージ側の診断ログを見てみます。 以下の通り、SMB アクセス、HTTPS アクセスいずれも CallerIpAddress は 10.11.0.122 となっています。 VNet 統合していないにもかかわらず、プライベート IP が用いられています。

このアドレスは、下記のドキュメントにおける「プライベートAzure IPアドレス」と考えられます。

Azure Storage ファイアウォールおよび仮想ネットワークを構成する

前述のApp Service 側のドキュメントには以下の記載があります。

アプリで VNET 統合を使用すると、マウントされたドライブは、VNET からの IP アドレスではなく RFC1918 IP アドレスを使用します。

アプリと Azure Storage アカウントが同じリージョンにある場合に App Service IP アドレスからのアクセスを Azure Storage ファイアウォール構成で許可しても、それらの IP 制限は適用されません。

参考

• Azure VM からストレージ アカウントへアクセスする際の挙動とアクセス元制御

この状態でストレージアカウント側のファイアウォールにてパブリックアクセスを無効にした場合、マウントした領域は見えなくなってしまいます。

VNet 統合を用いてPrivate Endpoint 経由でのアクセスを行う

App Service を Private Endpoint にアクセス可能な VNet に統合し、アプリケーション設定に WEBSITE_CONTENTOVERVNET = 1 を追加します。

以下のように WEBSITE_PRIVATE_IP としてサブネットから 10.0.1.254 が割り当てられており、ストレージアカウントの名前解決も 10.0.0.13 と PrivateEndpoint の IP を取得できる状態でマウントができています。

ストレージの診断ログ側では以下ように、CallerIpAddress は 10.0.1.254 とインスタンスに割り当てられた Private IP からのアクセスになっていることが確認できます。

また、ここでの注目点として、Uri が、\\toshidatempstorage.file.core.windows.net-10.0.1.254\myfiles\ と<ストレージアカウントのFQDN>-と変わっていることが確認できます。

これはどういうことかというと、アプリケーション上でのマウントは直接行われているわけではなく、App Service のプラットフォームにてマッピングが行われていることを示しております。 したがって、複数インスタンスが存在する場合などは、それぞれのIPで各インスタンス上でマッピングされることになります。

C:\local > storageAccountMappings.txt からこの情報を確認することができます。

以下のようなファイルアクセスも可能となります。 ただし、最下部で実施のように、PrivateIPを含まない場合でのアクセスはできません。

また、10.0.1.254 と別の Private IP を持つインスタンスでは以下のようになっており、\\toshidatempstorage.file.core.windows.net-10.0.1.254\myfiles\　にアクセスすることはできません。

診断ログも以下のように、10.0.1.253 10.0.1.254 それぞれのアクセスがあることがわかります。

トラブルシューティングのポイント

Private Endpoint を利用できる状態にあるか

まずは VNet 統合が正しくできていること、Private Endpoint にアクセス可能かどうかの見極めとして、 下記資料を参考に nameresolver や curl を用いてご確認くださいませ。

仮想ネットワークとAzure App Serviceの統合のトラブルシューティング

WEBSITE_CONTENTOVERVNET = 1 が設定されているか

Windows(コード)環境において、VNet 経由でのマウントを行う場合必須の設定となります。 ドキュメント上は見落としやすいためご注意ください。

UNCパスでファイルを参照していないか

Private Endpoint を利用したマウントを行った場合、UNCパスはインスタンス毎に異なります。 アプリケーションからはUNCパスではなく、マウント先と指定したパス C:\mounts\<path> としてアクセスしましょう。

ストレージアカウントの診断ログを有効にしているか

SMB クライアントとなる App Service がどのようなアクセスをおこなっているかはストレージアカウント側の診断ログから確認可能です。

ストレージアカウントの診断ログについては、下記ドキュメントをご参考にしてください。

https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-monitoring