Azure Storage や SQL Database で使えるようになっている Service Endpoint が App Service でも使えるようになりました。現在はパブリックプレビューなので、自由に試すことが出来ます。
中の人が書いているように、アプリの前に Application Gateway などを置きたい場合に使えます。
#AzureAppService Service Endpoints to your app is now live in preview. Go to your app > Networking > Access Restrictions and add a rule with a type of Virtual Network. Great with App Gateways or with the new VNet Integration to make multi-tier apps.
— Christina Compy (@ccompy) 2019年4月25日
これまでも App Service は IP アドレスでの制限が行えていましたが、特定の VNET に存在するサブネットからのアクセスだけ許可するといったような使い方が出来ます。
Access Restrictions からルールを追加する際に Virtual Network が増えているので、それを選択すると対象となる VNET とサブネットが選べるようになります。ちなみに新しい VNET Integration とは異なり、Free 含め全てのプランで使えるようです。
サブネットで Service Endpoint が有効化されていない場合はメッセージが表示されますが、そのまま追加すると自動的にそのサブネットの Service Endpoint が有効化されます。
先に手動で追加しておいても問題ありません。作成時のメッセージが消えるぐらいです。サブネットの設定を確認すると Microsoft.Web という Service Endpoint が有効化されています。
話を戻してルールの追加ですが、一度に複数のサブネットは選べないので、必要な分だけ都度追加していきます。Azure CLI でも追加できるようになるはずですし、ARM Explorer でも出来ます。
App Service は他の Service Endpoint とは UI が異なっていますが、挙動は Service Endpoint なので基本的には同じです。将来的に他に UI が合わせられる可能性もあるかもしれないですね。
例によって許可ルールを追加すると、暗黙的にそれ以外は全て拒否するルールが追加されます。
上のようにルールを追加すると、当然ながらインターネット経由ではアクセス出来なくなります。エラー画面は IP 制限の時と同じものが表示されます。
指定した VNET の特定サブネットからのみ許可されているので、そのサブネットに適当に VM を追加してアクセス出来るか試しました。これも当然ですが問題なくアクセスが行えました。
使い勝手は Azure Storage などと同じなので、特に使い方で悩むことはないでしょう。
これまでは ASE しか無理だった VNET 周りが必要な構成ですが、大幅に条件が緩和されましたね。
Private IP でのアクセスとかは無理ですが、大体は特定の VNET からだけアクセスを許可したいというケースだと思うので、今回の Service Endpoint で大体要件は満たせるのではないかと思います。
Application Gateway からアクセス
VM から叩いて終わりだと面白くないのと、久し振りに VNET を作成したので Application Gateway をデプロイして、バックエンドに Service Endpoint を有効化した App Service を置いてみました。
適当に新しいサブネットを追加して、そこに Application Gateway をデプロイしました。バックエンドプールには例の App Service を追加していきます。
今回の話とあまり関係ないですが、最近の Application Gateway はバックエンドに App Service を追加した場合には、HTTP settings から Use for App Service にチェックを入れると良い感じに設定してくれます。
App Service 側にも Application Gateway をデプロイしたサブネットを許可するようにルールを追加すると、問題なく Application Gateway 経由でしかアクセスできない構成を組めます。
Application Gateway にアクセスすると、ちゃんとバックエンドの App Service が持つページが返って来ます。
個人的には Application Gateway をフロントに置くよりも Front Door を使った方が良いと思いますが、どうしても VNET 内にデプロイする必要がある場合には使えると思います。
ちなみに上の構成も、これまでは ILB ASE を使わないとアクセス制限が面倒になってしまうものでした。
App Service からアクセス
現在プレビュー中の新しい VNET Integration を使うと Service Endpoint へのアクセスが行えるので、同様に App Service 間のアクセスを VNET 経由に出来ます。
新しい VNET Integration については以下のエントリを参考にしてください。
これでサクッと Service Endpoint を経由して App Service にアクセス出来るかと思っていましたが、現在 VNET Integration が一部で正しく動作していない気配があり、予想以上にはまってしまいました。
Storage への Service Endpoint でのアクセスも行えませんが、VNET 内にいる VM には問題なくアクセス出来るので、Azure 側の問題っぽいです。新しい Scale unit のバージョンだと直ってそうでした。
Central US に新しいバージョンがデプロイされていたので、新しく App Service を作成して VNET Integration の設定を行うと、Service Endpoint 経由で App Service にアクセス出来ました。
curl だけだとアレなので、いつも通り URL Rewrite を使ってリバースプロキシとして実行しておきます。以下のように Web.config を書いて、アクセス制限済みの App Service を見るようにします。
<?xml version="1.0" encoding="utf-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="backend" stopProcessing="true"> <match url="(.*)" /> <action type="Rewrite" url="https://daruyanagi1.azurewebsites.net/{R:1}" /> </rule> </rules> </rewrite> </system.webServer> </configuration>
これ以外にも XDT を使って ARR の有効化が必要ですが、今回は省略しておきます。
これでブラウザからアクセスすると、バックエンドへのリバースプロキシとして動作します。ページもちゃんと表示出来ていることが確認できます。
ちゃんと VNET に参加さえ出来ていれば、Service Endpoint 自体は問題なく動作しました。
検証のために App Service と Storage しか居ない VNET を作ってみましたが、VNET Integration と Service Endpoint が GA すれば VNET をアクセス制限のためだけに使うパターンも出てきそうですね。
将来的には指定したリソースからのみアクセス可能とかに出来れば良いと思いました。
Storage の場合は同じリージョンの VNET しかルールに追加できないみたいですが、App Service はどのリージョンの VNET でも対象に出来ました。意図した動作なのか分からないので、変わるかも知れません。
