このエントリは2024/03/09現在の情報に基づいています。将来の機能追加や変更に伴い、記載内容からの乖離が発生する可能性があります。
ちょっと前にと複数の人（いつもの人ではない）からカスタムドメインに関する質問をもらった。
問い合わせ
- 現在Application Gateway V2とApp ServiceでWebアプリケーションを作成している。今回、カスタムドメインを構成しつつ、TLSで接続を保護しようとしている。このとき、Application GatewayとApp Service、両方でカスタムドメインを構成する必要があるのか？
- VNetに閉じたAzure Container Apps (ACA) 環境の前段に、Private IPのみを拾うリスナーを立てたApplication Gateway + WAFを配置しようとしている。カスタムドメインを構成するにあたって、Application GatewayとACAでFQDNを一致させたいのだが、それって可能なのか？
- TLS証明書をKey Vaultに格納しているのだが、このKey VaultはVNetにPrivate Endpointで接続している。ちゃんと証明書を取得できるか？
1.については、クライアントからの接続はApplication Gateway (L7 Load balancer) に対してであり、背後にあるApp Serviceへの接続はApplication Gatewayが起点になっている。なので、カスタムドメインは通常だとApplication Gatewayだけでよいはずだが、どうしたものか、というお話。2.については、Application Gatewayとバックエンドプールに配置したACAでカスタムドメインを構成する場合、同じFQDNを使うことができるか、という話。
3.については、Key VaultをVNetに引き込んでいても大丈夫なのか、という話。
カスタムドメインの構成について
基本的にはApplication Gatewayだけに設定すれば事足りる。1.の場合、App Serviceをバックエンドプールのサービスとして利用しているので、Hostヘッダーをオーバーライドする必要がある。
具体的にどういうことか
Hostヘッダーを書き換えない場合、バックエンドプールのサービスに到達できない。App ServiceはHostが設定されていないと、目的のサービスに到達できないためである。そのため、レスポンスも返らない。
これに対処するために、
- Application Gatewayでバックエンドへの通信のために
Hostヘッダーを書き換える
という一手間（といってもAzure Portalならちょびっと設定するだけ）が必要。これにより、バックエンドプールのサービスがApplication Gatewayにレスポンスを返すので、クライアントが期待している通りにApplication Gatewayからレスポンスが到着する。
App Serviceをバックエンドプールに設定しているのであれば、ターゲットのホスト名を使うようにPortalで構成できる。このとき、
基本的に、ということは
もう一つ方法があって、
- Application Gatewayとバックエンドサービス（ここではApp Service）のFQDNを一致させる
というやり方もある。これは、Application Gatewayとバックエンドプールのサービス（App Service）のFQDNを一致させることで、FQDNのオーバーライドをしなくてすみ、バックエンドプールからのレスポンスをApplication Gatewayを経由してクライアントに返すことができる。この場合は、Hostのオーバーライドはしてはいけない。でもかなりトリッキーなのは事実。
この件は以下のサポートブログにも記載がある。
Application Gateway – App Service 間のリダイレクトの問題
https://jpaztech.github.io/blog/network/appgw-appservice-redirectissue/
Application Gateway での TLS 終端とエンド ツー エンド TLS の概要 / Overview of TLS termination and end to end TLS with Application Gateway
https://learn.microsoft.com/azure/application-gateway/ssl-overview
Private EndpointでVNetに接続したKey VaultからTLS証明書を取得する
これはサポートされた構成であり、問題なく構成できる。以下のドキュメントにも記載がある。
https://learn.microsoft.com/azure/application-gateway/key-vault-certs#verify-firewall-permissions-to-key-vault
ただ、どうしてもうまくいかない場合には、いささかトリッキーではあるが、Application GatewayがKey Vaultにとっての「信頼できるサービス」であることを使い、Key VaultのFirewallをバイパスする、という方法も利用できる。この仕組みは、Key VaultがPrivate EndpointでVNetに引き込まれていたとしても有効。
信頼できるサービス / Trusted services
https://learn.microsoft.com/azure/key-vault/general/overview-vnet-service-endpoints#trusted-services
なお、Key Vaultの全てのユースケースでのアクセスが許可されているわけではなく、今回のようなからTLS証明書を取得する場合に限定されている。また、アクセス制御にあたっては、以下の点に注意が必要。
- Application GatewayからのアクセスではManaged Identityを構成する（Application GatewayにはSystem managed identityはないので、User managed identityを使う必要がある）
- Keyコンテナーのポリシーでアクセス制御する必要がある（Azure RBACは現時点では利用できない）
Azure Portalだと、以下のようなチェックボックスが選択されたネットワーク（Service Endpoint）、Private Endpointのいずれでも構成が可能。
Front Doorの場合は以下のエントリにもちょびっと記載していた。
Logico Inside 