しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

App Service から Azure Monitor Private Link Scope 経由で Application Insights を利用する

先日 Workspace ベースの Application Insights を弄っていた時に Network Isolation という設定が目に入り、そういえば Private Link Scope ってよく分かっていないと思ったのでデプロイして試しました。

単純に Azure Monitor へのアクセスを Private Endpoint 経由するためのサービスですが、Azure Monitor は他のサービスと異なり色々なもの組み合わせで作られているので、この Private Link Scope で境界を定義する必要があるようです。微妙に分かりにくい感あります。

ドキュメントでは使うためにサインアップが必要とありましたが、手持ちのサブスクリプションでは何もせずにデプロイが出来ました。片倉さん曰く GA しているらしいので、全てで使えるようになっていそうです。

一応は今回紹介する機能は Workspace ベースの Application Insights 限定のようです。*1

Private Link Scope と Private Endpoint のデプロイ

Private Link Scope のデプロイについては片倉さんのブログに丸投げします。ターゲットは Linux の VM ですが、構築の手順が順を追って分かりやすく書かれています。

Private Link Scope のデプロイ後、Private Endpoint のデプロイも必要になるのを少し忘れそうでした。

実際に Private Link Scope に対して Private Endpoint を追加すると沢山の Private DNS Zone がデプロイされます。ドメイン名の一貫性のなさに闇を感じつつ、Private Link Scope が必要な理由を垣間見られます。

f:id:shiba-yan:20200929003025p:plain

この VNET には Cosmos DB と Key Vault の Private Endpoint をデプロイ済みなので更に増えています。

後は Private Link Scope に対して Private Endpoint 経由でアクセスしたい Application Insights や Log Analytics Workspace を追加します。ちなみに 1 つの Application Insights / Log Analytics Workspace に対して、複数の Private Link Scope を紐づけることも出来るようです。

f:id:shiba-yan:20200929002023p:plain

これで Private Link Scope の設定は完了しましたが、最後に Application Insights の Network Isolation から Public アクセスを有効にするかどうかを設定します。この設定をしないとロックダウン出来ません。

今回は Ingest だけ Public アクセスをオフにしました。Query に対してオフにすると Azure Portal からの確認するために VNET 経由で行う必要があり、流石に面倒だったからです。

f:id:shiba-yan:20200929011654p:plain

Application Insights に紐づけている Log Analytics Workspace に対しても、同じように Public アクセスをオフにしておきます。何故か Azure Portal には Network Isolation の設定が見当たりませんでしたが、ARM Explorer を使うことで変更できました。

ここまでの作業で Application Insights へのテレメトリ送信は Private Endpoint 経由でしか出来なくなっているはずです。動作確認は App Service や Azure Functions からいつも通りテレメトリを送信すれば良いです。

App Service / Azure Functions からテレメトリを送信

当然ながら Private Endpoint 経由で送信するためには、App Service では Regional VNET Integration の追加かつ WEBSITE_VNET_ROUTE_ALLWEBSITE_DNS_SERVER の設定が必要になります。

この辺りは何回も書いているので以前のエントリを参照してください。再起動が必要な時もあります。

無事に Private Endpoint を使う準備が出来ていれば、Kudu の Debug Console などを使って Application Insights の IngestionEndpoint への IP アドレスを引いてみると、Network Interface に割り当てられた IP アドレスが返ってくるはずです。

nslookup を使うと 2 回タイムアウトしましたが、App Service 向けに用意されている nameresolver を使うと綺麗に IP アドレスを引けます。

f:id:shiba-yan:20200929002545p:plain

この状態で Azure Portal から Live Metrics を確認しつつ、適当なページへのアクセスや Function を実行してテレメトリを送信すると、これまで通りリクエスト数などの情報を確認できます。

f:id:shiba-yan:20200929011148p:plain

確認できたので App Service / Azure Functions 側で WEBSITE_VNET_ROUTE_ALLWEBSITE_DNS_SERVER の設定を落として再度試すと、今度は全くテレメトリが流れてこないことが確認できます。

f:id:shiba-yan:20200929011156p:plain

これで Application Insights へのテレメトリを Private Endpoint 経由で、これまで以上に安全に送信できるようになりました。Query の Public アクセスについては本番でら閉じましょう。

今回は Azure Functions だったので試していませんが、Profiler や Snapshop Debugger を使う場合には、以下のように独自のストレージアカウントを持ち込んで設定する必要があるようです。

正直なところあまり使う機会は無いかもしれませんが、Private Link Scope が必要なケースではこの辺りもしっかり押さえておく必要があるでしょう。

そもそもログにセンシティブなデータを書き出すなという話ですが、メモリダンプには何が含まれるのか分からないのでかなり注意深く扱う必要があります。*2

*1:Classic でも使えそうな気はしたけど試してません

*2:本番で Snapshot Debugger を使うかどうかはまた別の話