Azure Application Gateway V2 に App Service Certificate を使って HTTPS を構成する

Azure Application Gateway V2 のエンドポイントには IP アドレスが割当されますが、 バックエンドに Azure Active Directory B2C などで認証したアプリケーションを置くと、リダイレクト先として HTTPS のエンドポイントが必要となります。
カスタムドメインの HTTPS を構成する流れは公式ドキュメント通りですが、補足を加えてまとめました。
docs.microsoft.com
証明書のカスタムドメインには、Azure の App Service Domain を使いました。必ずしも Azure で購入する必要はありませんが、Azure Portal で購入手続きが完結できるメリットがあります。

事前準備

Azure Application Gateway V2 のエンドポイントに設定するカスタムドメインと証明書を用意します。App Service Domain と App Service Certificate の購入方法については、別の記事を参照してください。
gooner.hateblo.jp
本題ではないので、Azure Application Gateway V2 にバックエンドのアプリケーションを構成する部分は割愛します。今回は、.NET Core 向けの Web Apps をバックエンドに設定しました。

Azure Application Gateway V2 にカスタムドメインを構成する

App Service Domain を購入したときに作られた DNS zone を開きます。Azure Application Gateway V2 のパブリック IP アドレスを使って、demo.gunner-s.com というドメインのAレコードを追加します。
Aレコードの追加が反映されると、Azure Application Gateway V2 に HTTP のカスタムドメインでアクセスできるようになります。

App Service Certificate を Key Vault で管理する

Azure App Service 以外のリソースで App Service Certificate を利用するには、証明書を Key Vault で管理する必要があります。まず、証明書をエクスポートしますが、今の Azure Portal ではできないので、Azure PowerShell を使います。
azure.github.io

公式ドキュメントの通りに Export-AppServiceCertificate 関数を追加して実行すると、ローカルに証明書の PFX ファイルをエクスポートできます。忘れずに、実行結果に表示されるパスワードをメモしておきましょう。

Export-AppServiceCertificate -loginId yourarmemail@domain.com -subscriptionId yoursubid -resourceGroupName resourceGroupNameOfYourAppServiceCertificate -name appServiceCertificateName

続いて、Azure PowerShell でエクスポートした PFX ファイルを、Key Vault の証明書メニューからインポートします。

最後に Key Vault の Soft Delete の設定を有効にしておきます。Azure Application Gateway などの他のリソースから証明書を参照するために必要な設定です。

Azure Application Gateway V2 に HTTPS を構成する

Azure Application Gateway から Key Vault で管理している証明書にアクセスできる権限を付与する必要があります。
Azure Portal から User Assigned Managed Identity を開き、appgw-identity という Managed Identity を登録します。リソースグループは、Azure Application Gateway と同じものを選択しました。

Azure Portal から Key Vault を開き、登録した Managed Identity に Key Vault のアクセスポリシーを付与します。シークレットに GET のパーミッションが必要です。アクセスポリシーを追加した後、忘れずに保存ボタンを押しましょう。

これで準備が整ったので、Azure Application Gateway で HTTPS を構成したリスナーを追加します。Key Vault から証明書を参照して構成することができます。

リスナーを追加できたら、ルールを変更します。

これで Azure Application Gateway の構成が完了です。HTTPS のカスタムドメインでアクセスできるようになります。

まとめ

Azure Application Gateway V2 に App Service Certificate を使って HTTPS を構成してみました。
App Service Certificate は App Service 以外でも使えますし、Key Vault の連携部分を押さえておけば、Azure Portal だけで購入手続きが完結し、安全に管理することができるので、検証目的に使うのはアリかなと思います。

Azure の App Service Domain と App Service Certificate を使ってカスタムドメインの HTTPS を構成する

Azure の App Service Domain と App Service Certificate を購入し、いくつかのリソースに対して、カスタムドメインの HTTPS を構成してみました。
必ずしも Azure で購入する必要はありませんが、Azure Portal で購入手続きが完結し、Azure Key Vault で安全に管理することができるメリットがあります。

App Service Domain

Azure Portal から、App Service Domain を選択してドメインを購入します。ドメイン名のほかに、連絡先情報など入力するだけです。もちろん、App Service 以外でも使えるドメインです。今回は、gunner-s.com というドメインを購入しました。

購入できるドメインは、GoDaddy で管理されていて有効期間は１年間です。自動更新がデフォルトで設定されています。

App Service Certificate

App Service Certificate から証明書を購入します。似た名前の App Service Managed Certificates という無料のサービスもありますが、まだプレビューとなります。
今回は、demo.gunner-s.com というドメインをワイルカードなしで購入しました。ワイルドカードが使える証明書を購入できるプランもあります。

証明書を使えるようにするため、いくつかのステップが必要となります。
まずは、Azure Key Vault へ証明書をインポートします。App Service 以外から証明書を参照するためには、soft delete の設定を有効にする必要があるので、専用の Key Vault を用意したほうがいい気がします。

次に、ドメインの検証です。画面に表示される Domain Verification Token をコピーしておきます。

App Service Domain を購入したときに作られた DNS zone を開きます。コピーした Domain Verification Token を使って、demo.gunner-s.com というドメインのTXTレコードを追加します。

TXTレコードを追加したら、App Service Certificate の画面に戻って検証ボタンを押すと、5分ほどで検証が完了します。

Azure App Services にカスタムドメインの HTTPS を構成する

Azure App Services の場合、Azure Portal からさくっとカスタムドメインの HTTPS を構成できます。

1. Azure DNS zone で、CNAMEレコードを登録する
2. Azure App Services でカスタムドメインを割り当てる
3. Azure App Services で App Service Certificate をインポートする

公式ドキュメントの通りなので、詳しい手順は割愛します。
docs.microsoft.com
docs.microsoft.com

下記のように、Azure App Services にカスタムドメインの HTTPS でアクセスできるようになります。

Azure App Services 以外のリソースにカスタムドメインの HTTPS を構成する

Azure App Services 以外のリソースに対して、カスタムドメインの HTTPS を構成してみます。

• Application Gateway V2
• Azure Storage Static website + CDN

記事を分けたので、下記のリンクを参照してください。
gooner.hateblo.jp
gooner.hateblo.jp

まとめ

Azure の App Service Domain と App Service Certificate を購入し、いくつかのリソースに対して、カスタムドメインの HTTPS を構成してみました。
本番運用で使うこともできますが、Azure Portal だけで購入手続きが完結し、Azure Key Vault で安全に管理することができるので、検証目的に使うのはアリかなと思います。

Azure Pipelines で Variable groups を使ってパイプラインを構築する

先日の記事で、Azure DevOps の Multi-Stage Pipelines を使って Azure Web Apps にデプロイする内容を記載しました。
gooner.hateblo.jp
YAML をソースコードのリポジトリで管理する想定なので、環境毎に異なる情報やパスワードなどのシークレットな情報をリポジトリに含めたくありません。そこで、Azure DevOps の Variable groups を使って、パイプラインを書き換えてみました。

パイプラインの全体設計

先日の記事と同様に、パイプラインは、自動デプロイされる開発環境向け（Commit Stage）と承認デプロイされる本番環境向け（Production Stage）を作りました。
YAML を Build と Release に分けて、可変部をパラメータで切り替えできるテンプレートを作ることで再利用性を向上させます。

Variable groups とは

Variable groups は、Azure DevOps 内に定義した Key-Value のデータをグループ化し、YAML パイプラインに渡すことができる機能です。
docs.microsoft.com
Azure DevOps の Library メニューから Variable groups を登録します。このユースケースでは、ブランチ毎にデプロイ先の Azure Web Apps が異なるので、Commit Stage と Production Stage でグループを分けて、webAppsName を登録します。
variable-group-commit と variable-group-production の２つの Variable groups を登録しました。

今回は利用しませんが、パスワードなどのシークレットな情報は、Value の右横の鍵マークをクリックすると、値をマスクすることができ、登録した人以外には非公開にすることも可能です。また、Azure Key Vault で値を管理することもできます。

パイプライン

変更する YAML は、パイプライン起動用の azure-pipelines.yml です。

trigger:
- master

variables:
- group: variable-group-commit
- name: imageName
  value: 'windows-2019'
- name: buildConfiguration
  value: 'Release'
- name: projects
  value: '**/WebApplication.csproj'
- name: testProjects
  value: '**/WebApplication.Tests.csproj'
- name: azureSubscription
  value: 'AzureSponsorships'
- name: webAppsType
  value: 'webApp'
- name: environment
  value: 'Commit-Stage'

stages:
- stage: Build
  jobs:
  - template: pipelines/build-pipelines.yml
    parameters:
      imageName: $(imageName)
      buildConfiguration: $(buildConfiguration)
      projects: $(projects)
      testProjects: $(testProjects)
    
- stage: Release
  dependsOn:
  - Build
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
  jobs:
  - template: pipelines/release-pipelines.yml
    parameters:
      imageName: $(imageName)
      azureSubscription: $(azureSubscription)
      webAppsName: $(webAppsName)
      webAppsType: $(webAppsType)
      environment: $(environment)

variables の webAppsName を削除する代わりに、group: variable-group-commit を追加することで、Variable groups から値を受け取ることができます。
Variable groups と YAML に定義する variables の両方を使いたいので、既存の variables を name-value 形式で書き換えています。
同様の手順で、本番環境向けパイプラインの azure-pipelines-production.yml も変更すれば、完了です。

まとめ

YAML をソースコードのリポジトリで管理する場合、環境毎に異なる情報やパスワードなどのシークレットな情報をリポジトリに含めたくありません。
Azure DevOps の Variable groups を使うことで、YAML パイプラインに値を渡すことができるので、実プロジェクトに適用する際にはうまく活用したい機能です。
こちらから、パイプライン YAML の全体を確認できます。
github.com