こんにちは、ACS 事業部の埜下です。

Terraform を元にした Azure Front Door 解説記事の第 3 弾です。今回は Azure Front Door でのカスタムドメインを利用する方法について解説していきます。

その他の記事はこちらになります。

Azure Front Door の構成（おさらい）
Azure Front Door のドメイン
カスタムドメインの選択
Terraform でカスタムドメインを構築
BYOC ベースのドメイン所有権の検証
App Service 証明書利用時の注意点
おわりに
参照資料
ACS事業部のご紹介

Azure Front Door の構成（おさらい）

カスタムドメインの話の前に Azure Front Door 構成のおさらいです。 Azure Front Door はいくつかのコンポーネントで構成されていまして、Terraform で構築する場合に最低限必要なリソースは以下になります。

プロファイル (azurerm_cdn_frontdoor_profile)
エンドポイント (azurerm_cdn_frontdoor_endpoint)
配信元グループ (azurerm_cdn_frontdoor_origin_group)
配信元 (azurerm_cdn_frontdoor_origin)
ルート (azurerm_cdn_frontdoor_route)

これらのリソースを使って Azure Front Door を構築する Terraform コードは以下のようになります（バックエンドとして配置している App Service のリソースは省略）。

# プロファイル
resource "azurerm_cdn_frontdoor_profile" "demo" {
  name                = "afd-demo"
  resource_group_name = azurerm_resource_group.demo.name
  sku_name            = "Premium_AzureFrontDoor"
}

# エンドポイント
resource "azurerm_cdn_frontdoor_endpoint" "demo" {
  name                     = "fde-demo"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.demo.id
}

# 配信元グループ
resource "azurerm_cdn_frontdoor_origin_group" "demo" {
  name                     = "demo-origin-group"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.demo.id

  load_balancing {}
}

# 配信元
resource "azurerm_cdn_frontdoor_origin" "demo" {
  name                          = "demo-origin"
  cdn_frontdoor_origin_group_id = azurerm_cdn_frontdoor_origin_group.demo.id

  host_name                      = azurerm_linux_web_app.demo.default_hostname
  origin_host_header             = azurerm_linux_web_app.demo.default_hostname
  certificate_name_check_enabled = true
}

# ルート
resource "azurerm_cdn_frontdoor_route" "demo" {
  name                          = "demo-route"
  cdn_frontdoor_endpoint_id     = azurerm_cdn_frontdoor_endpoint.demo.id
  cdn_frontdoor_origin_group_id = azurerm_cdn_frontdoor_origin_group.demo.id
  cdn_frontdoor_origin_ids      = [azurerm_cdn_frontdoor_origin.demo.id]

  patterns_to_match   = ["/*"]
  supported_protocols = ["Http", "Https"]
}

クライアントからのリクエストに対してこれらのリソースがどのように繋がっているかのイメージは以下になります。

Azure Front Door のドメイン

Azure Front Door でエンドポイントを作成すると azurefd.net という既定のドメインが割り当てられます。既定のドメインのままでも Azure Front Door でのコンテンツ配信は可能ですが、ユーザ側で持っているドメインを「カスタムドメイン」としてエンドポイントに割り当てることも可能です。

カスタムドメインにはユーザがドメイン登録サービスから購入したドメインを使用することも、Azure から購入する App Service ドメインを使用することもできます。

カスタムドメインの選択

Terraform のコードを見ていきたいところですが、カスタムドメインを使う際には以下の選択項目があります。選択した内容によって Terraform リソースも使用有無が決まりますので、まずはどのような選択項目があるか説明していきます。

ドメインの種類
DNS の管理
証明書の種類

ドメインの種類

まずは「ドメインの種類」です。 Azure Front Door で使用するカスタムドメインが以下のどちらなのかを選択します。

Azure 以外の検証済みドメイン
Azure 内で事前検証済み

「Azure 以外の検証済みドメイン」はドメインの所有権を検証する必要があります。ドメイン所有権の検証は最近アップデートがあったため後ほどで紹介します。

「Azure 内で事前検証済み」を選択するとドメイン所有権の検証は不要になります。ただし、現時点では Static Web App で検証されたドメインのみがサポート対象となる点は注意が必要です。

現時点で Terraform を使って「Azure 内で事前検証済み」を構築する方法が見当たらないので、今回は「Azure 以外の検証済みドメイン」に絞って説明します。

DNS の管理

ドメインの種類で「Azure 以外の検証済みドメイン」を選択した場合は「DNS の管理」を選択しなければなりません。選択肢としては以下があります。

Azure マネージド DNS
その他すべての DNS サービス

「Azure マネージド DNS」を選択した場合は、既存の Azure DNS ゾーンを指定します。ドメイン所有権の検証時に指定した Azure DNS ゾーンに検証用の TXT レコードが作られます。

「その他すべての DNS サービス」の場合、Azure Front Door 上ではドメイン名の指定のみになりますが、ドメインを管理している DNS サービスでユーザが検証用 TXT レコードを作成する必要があります。

証明書の種類

最後に「証明書の種類」です。こちらは上記の「ドメインの種類」や「DNS の管理」の内容に関わらず以下から選択する必要がある項目です。

AFD マネージド証明書
Bring Your Own Certificate (BYOC)

「AFD マネージド証明書」を選んだ場合、カスタムドメインが使用する証明書は Azure Front Door （もしくは Static Web App）によって発行、管理されます。

「Bring Your Own Certificate (BYOC)」、つまりユーザ管理の証明書の場合はひと手間かかります。やることとしては以下になります。

証明書を Azure Key Vault に格納
Azure Key Vault の証明書を指定して Azure Front Door にシークレットを作成
カスタムドメインの証明書にシークレットを指定

もちろん証明書の有効期限が切れる前にローテーションするのはユーザ側の責務になります。 特別な要件がない限りは Azure も推奨している「AFD マネージド」証明書を選択することをオススメします。

また、BYOC として App Service 証明書を利用することも可能です。しかし、App Service 証明書の利用時には注意点がありますので後述します。

あとは TLS の最小バージョンとして「TLS 1.0」or「TLS 1.2」という選択があるのですが、そのままの意味ですので説明は割愛します。

Terraform でカスタムドメインを構築

文章が多くなってしまったので、そろそろ Terraform のコードを見ながら Azure Front Door のカスタムドメインを説明していきましょう。

今回は新たに azurerm_cdn_frontdoor_custom_domain と azurerm_cdn_frontdoor_secret というリソースが登場します。名前のとおり azurerm_cdn_frontdoor_custom_domain はカスタムドメインを示すリソースなので今回は必須です。 azurerm_cdn_frontdoor_secret は「証明書の種類」で「Bring Your Own Certificate (BYOC)」を選択した際に使用するリソースなので場合によっては登場しませんが、今回はどちらのパターンも紹介します。

AFD マネージド証明書

AFD マネージド証明書を選択した場合、Terraform の各リソースは以下のような関係性になります。追加したカスタムドメインはプロファイルおよびルートと関連付けられます。

上図は ER 図のような表記ではありませんので文章で補足すると、ルートとカスタムドメインは「1 対多」の関係になります。つまり、一つのエンドポイントで複数のカスタムドメインを使用することが可能です。

そして Terraform コードは以下になります。

# カスタムドメイン（マネージド証明書）
resource "azurerm_cdn_frontdoor_custom_domain" "demo" {
  name                     = "custom-domain-managed-certificate"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.demo.id
  host_name                = "afd.example.com"

  tls {
    certificate_type    = "ManagedCertificate"
    minimum_tls_version = "TLS12"
  }
}

# ルート
resource "azurerm_cdn_frontdoor_route" "demo" {
  name                          = "demo-route"
  cdn_frontdoor_endpoint_id     = azurerm_cdn_frontdoor_endpoint.demo.id
  cdn_frontdoor_origin_group_id = azurerm_cdn_frontdoor_origin_group.demo.id
  cdn_frontdoor_origin_ids      = [azurerm_cdn_frontdoor_origin.demo.id]

  patterns_to_match   = ["/*"]
  supported_protocols = ["Http", "Https"]

  # エンドポイントに関連付けるカスタムドメインの指定
  cdn_frontdoor_custom_domain_ids = [azurerm_cdn_frontdoor_custom_domain.demo.id]

  # 既定のドメイン使用有無
  link_to_default_domain = true
}

azurerm_cdn_frontdoor_custom_domain リソースではプロファイルの指定やカスタムドメイン名の設定のほか、tls ブロックで証明書の種類を選択します。 AFD マネージド証明書の場合は ManagedCertificate を指定することになります。

そして azurerm_cdn_frontdoor_route リソースではエンドポイントに関連付けるカスタムドメインを引数 cdn_frontdoor_custom_domain_ids に指定します。

また、引数 link_to_default_domain にて「既定のドメインをエンドポイントで使用するか」を選択することができます。 true の場合はカスタムドメインと既定のドメインの両方からコンテンツを配信可能となり、false の場合はカスタムドメインのみ配信可能となります。

Bring Your Own Certificate (BYOC)

つづいて BYOC のパターンです。

AFD マネージド証明書と異なりシークレットが必要です。そしてシークレットは Azure Key Vault に格納された証明書を参照します。

Terraform のコードにも Azure Key Vault に格納された証明書を指定した azurerm_cdn_frontdoor_secret リソースを追加します。また、カスタムドメイン azurerm_cdn_frontdoor_custom_domain リソースでは tls ブロック内で参照するシークレットを指定します。

# カスタムドメイン用シークレット
resource "azurerm_cdn_frontdoor_secret" "demo" {
  name                     = "custom-domain-secret"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.demo.id

  secret {
    customer_certificate {
      key_vault_certificate_id = azurerm_key_vault_certificate.demo.id
    }
  }
}

# カスタムドメイン (BYOC)
resource "azurerm_cdn_frontdoor_custom_domain" "demo" {
  name                     = "custom-domain-customer-certificate"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.demo.id
  host_name                = "afd.example.com"

  tls {
    certificate_type        = "CustomerCertificate"
    minimum_tls_version     = "TLS12"
    cdn_frontdoor_secret_id = azurerm_cdn_frontdoor_secret.demo.id
  }
}

# ルート
resource "azurerm_cdn_frontdoor_route" "demo" {
  name                          = "demo-route"
  cdn_frontdoor_endpoint_id     = azurerm_cdn_frontdoor_endpoint.demo.id
  cdn_frontdoor_origin_group_id = azurerm_cdn_frontdoor_origin_group.demo.id
  cdn_frontdoor_origin_ids      = [azurerm_cdn_frontdoor_origin.demo.id]

  patterns_to_match   = ["/*"]
  supported_protocols = ["Http", "Https"]

  # エンドポイントに関連付けるカスタムドメインの指定
  cdn_frontdoor_custom_domain_ids = [azurerm_cdn_frontdoor_custom_domain.demo.id]

  # 既定のドメイン使用有無
  link_to_default_domain = true
}

ルート azurerm_cdn_frontdoor_route リソースは前述のパターンと同じ内容になります。

DNS ゾーン

上記で紹介したパターンは DNS の管理で「その他すべての DNS サービス」を選択した場合の例になります。「Azure マネージド DNS」を選択する場合、カスタムドメイン azurerm_cdn_frontdoor_custom_domain リソースで DNS ゾーンを指定する他、ドメイン所有権の検証用 TXT レコード azurerm_dns_txt_record リソースを追加します。

azurerm_dns_txt_record リソースではレコード名に _dnsauth という文字列を追加し、値にはカスタムドメインで生成される検証用トークンを指定します。

# カスタムドメイン（マネージド証明書）
resource "azurerm_cdn_frontdoor_custom_domain" "demo" {
  name                     = "custom-domain-customer-certificate"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.demo.id
  host_name                = "afd.example.com"

  # DNS ゾーンを指定
  dns_zone_id              = azurerm_dns_zone.demo.id

  tls {
    certificate_type        = "ManagedCertificate"
    minimum_tls_version     = "TLS12"
  }
}

# ドメイン所有権の検証用 TXT レコード
resource "azurerm_dns_txt_record" "demo" {
  name                = join(".", ["_dnsauth", "afd"])
  zone_name           = azurerm_dns_zone.demo.name
  resource_group_name = azurerm_resource_group.demo.name
  ttl                 = 3600

  record {
    value = azurerm_cdn_frontdoor_custom_domain.demo.validation_token
  }
}

# ルート
resource "azurerm_cdn_frontdoor_route" "demo" {
  name                          = "demo-route"
  cdn_frontdoor_endpoint_id     = azurerm_cdn_frontdoor_endpoint.demo.id
  cdn_frontdoor_origin_group_id = azurerm_cdn_frontdoor_origin_group.demo.id
  cdn_frontdoor_origin_ids      = [azurerm_cdn_frontdoor_origin.demo.id]

  patterns_to_match   = ["/*"]
  supported_protocols = ["Http", "Https"]

  # エンドポイントに関連付けるカスタムドメインの指定
  cdn_frontdoor_custom_domain_ids = [azurerm_cdn_frontdoor_custom_domain.demo.id]

  # 既定のドメイン使用有無
  link_to_default_domain = true
}

BYOC ベースのドメイン所有権の検証

先月、Azure Front Door で BYOC を使ったドメイン所有権の検証可能になるというアップデートがありました。

azure.microsoft.com

これにより、ユーザが格納した証明書の証明署名 (CN) またはサブジェクト代替名 (SAN) が Azure Front Door のカスタムドメイン名と一致した場合に、ユーザがドメイン所有権を持っていると判断されるようになりました。これまでのように TXT レコードを格納して検証する手間を考えると、このアップデートによりカスタムドメイン使用時の運用負荷が下がるのではないでしょうか。

ちなみに、AFD マネージド証明書を選択した場合はこれまでどおり TXT レコードによる検証が行われます。

App Service 証明書利用時の注意点

先述したとおり、Azure Front Door カスタムドメインの証明書として App Service 証明書を利用することも可能です。

App Service 証明書を購入すると Azure Key Vault に証明書を格納することになりますが、App Service 証明書を格納する Azure Key Vault のアクセス許可モデルは「コンテナーのアクセスポリシー」しかサポートされていません。

Azure Portal などでは Azure Key Vault のアクセス許可モデルは「Azure ロールベースのアクセス制御」、所謂 RBAC が推奨となっているのでこちらを選択する場合が多いと思います。しかし、アクセス許可モデルが RBAC の Azure Key Vault は App Service 証明書の格納先として選択できないためご注意ください。

learn.microsoft.com