このエントリは2025/02/26現在の情報に基づいています。将来の機能追加や変更に伴い、記載内容からの解離が発生する可能性があります。
このエントリは以下のエントリの続き。
問い合わせ
久しぶりの方から以下のようなお問い合わせをもらった。
ACAのPrivate Link Service接続 (2025/02/26現在Public Preview) を使い、ACAをOriginとして、Azure Front Doorからアクセスできるようにしたい。同一ACA環境上に2個のACAを作成し、これらとFront Doorを接続し、パスベースルーティングを構成したいのだが、構成上注意すべきポイントはあるか？
そこまで複雑ではないはずなので、ルーティングとパスの関係を記載したドキュメントを紹介したのだが、「やっぱりよくわからん」ということらしい。
ルーティング アーキテクチャの概要 / Routing architecture overview
https://learn.microsoft.com/azure/frontdoor/front-door-routing-architecture
要求とルート構成のマッチング方法 / How requests get matched to a route configuration
https://learn.microsoft.com/azure/frontdoor/front-door-route-matching
もう少し前提条件や実現したいことを尋ねてみた。
- ACA1、ACA2は同一ACA環境で動作する
- ACA1のホストするAPIは
/caller、ACA2のホストするAPIは/env/headersというコンテキストパスを持つ - Front DoorからACA1、ACA2にはそれぞれ、
/app1と/app2というパスでルーティングさせたいhttps://<Front Door endpoint>/app1で、ACA1がホストするAPIのコンテキストパスが備えた呼び出しを実現したいhttps://<Front Door endpoint>/app2で、ACA2がホストするAPIのコンテキストパスを備えた呼び出しを実現したい
- 指定のパス以外での呼び出しは抑止したい
トポロジーは以下のよう。
構成状況を確認したところ、以下のようだった。
- エンドポイントは1個
- Origin GroupはACA1、ACA2の2個分作成
- OriginとしてACA1、ACA2を作成（接続はPrivate Link Serviceを利用）
- ルートはOrigin Groupごとに1個ずつ（合計2個）作成
- エンドポイントに2個のルートを関連付け
問題の箇所
以下の2箇所に問題があった。
- パスベースルーティングしたいにも関わらず、一致するパターン（Patterns to match）を明示的に指定していなかった（デフォルト（
/*）のままだった） /app1、/app2でAPIを呼び出せるようにしたいのに、配信元のパス（Origin path）を指定していなかった
勘のいい人ならわかったかもしれない。
対処法
ルートを以下のように書き換える必要がある。この構成はStandard、Premium共通。
| ルート | “一致するパターン” (Path to match) | “配信元のパス” (Origin path) |
|---|---|---|
| ACA1へのルート | /app1 | /caller |
| ACA2へのルート | /app2 | /env/headers |
これでおしまい。
例によって更問が届く
ご多分に漏れず更問が届いた。
ACA2がホストするAPIの呼び出しへのルーティングを、
/app2ではなく、/app2/headersというパスで実現したい場合、どうしたらいいか？/app2/*でもよさそうに見えるが、/app2/headersでなければならない理由があるか？
/app2/*と/app2/headersの違いは、以下のドキュメントにある通り、ワイルドカードで拾う（switch caseにおけるdefaultみたいなもの）場合には前者、完全一致させたいなら後者。
要求とルート構成のマッチング方法 / How requests get matched to a route configuration
https://learn.microsoft.com/azure/frontdoor/front-door-route-matching
Origin pathを完全に隠蔽したい意図がある場合、明示的に/app2/headersを一致するパターンとして設定すべきである。
Origin pathを隠蔽したいのに/app2/*を設定しているとどうなるのか？
今回の例の場合、確かにOrigin pathとして/envに書き換えることで、/app2/headersへのルーティングは可能である。ただし、この設定では/app2/footerなどといった呼び出しでも、Front DoorはOriginにルーティングしてしまう。もしOriginが/env以下のパスにリクエストを受けたときに余計なレスポンスを返すような実装だとすれば、攻撃者にとって有用な情報が漏洩する可能性がある。そのため、Origin隠蔽したいのであれば明示的に指定すべきである。
そんなこんなで更問その2が届いた。
Front Doorの設定を変更したが、反映に時間が掛かっている。なんとかできないか？
Application Gatewayの感覚でFront Doorを使おうとしているようだが、FAQに記載の通り、相応の時間が掛かる。
- Azure Front Door のデプロイにかかる推定時間はどのくらいですか? 更新プロセス中も Front Door は動作し続けますか? / What is the estimated time for deploying an Azure Front Door? Does my Front Door remain operational during the update process?
- Azure Front Door では、Front Door ルール エンジンに追加された新しいルールを適用するためにどのくらいの時間が必要ですか? / How much time does Azure Front Door require to apply a new rule added to the Front Door Rules Engine?
Edgeのキャッシュ削除をするというのも手ではあるが、やっていることはコンテンツやルールの伝播と本質的に変わらないので、Application Gatewayとは勝手が違うことは念頭に置くべきである（「知らんがな、それはFront Doorに聞いてくださいな」と言いそうになったがさすがに自重）。
Logico Inside 