はじめに
masamoriです。
App ServiceにはGithub Actionsを利用したCI/CDパイプラインを手軽に構築できる機能が備わっています。
Azure portaで App Service >>デプロイセンター と辿ると、設定できる画面に遷移できます。
自分の場合、既存のプロジェクトを改修する場合ならともかく、新規プロジェクトでApp serviceを使用する場合、デプロイツールはGithub Action一択という感じです。
さて、デプロイ時の認証方法には
- ユーザー割り当てID
- 基本認証(Basic authentication).
の2択から選択できます。推奨の認証はユーザー割り当て認証です。
ユーザー割り当て認証
ユーザー割り当て認証を使用すると、App serviceによって OpenID Connect認証を有効にするためのリソースが自動生成されます。具体的には.
- AZURE_CLIENT_ID
- AZURE_TENANT_ID
- AZURE_SUBSCRIPTION_ID.
が生成されます。いわゆるサービスプリンシパルを作成し、App Serviceのスロットに対して必要な権限を割り当ててくれます。サービスプリンシパルについての解説はSIOSの武井さんの記事に詳しく書かれています。
ユーザー割り当て認証を選択して、Workflowsファイルを作成するとスロットに対して「Webサイト共同作成者」がそのリソースに対して割り当てられます。
このマネージドIDを使用して、Githubに対する認証を適切にコントロールしています。
こちらの認証はJWTを使った認証なので、基本認証に比べればトークンベースの認証なので安全です。仮にトークンが流出しても時間が経てば失効します。
基本認証
一方、基本認証とはデプロイ資格情報を使って認証をします。デプロイ資格情報には以下2種類あります。
- ユーザー レベルの資格情報
- アプリ レベルの資格情報
Actionsで使用される資格情報はアプリレベルでの資格情報で、これがGithub のシークレットとして保存されます。
なお、この資格情報はApp Serviceの概要欄から取得することが可能です。
.
ちなみに基本認証は非推奨です。資格情報はApp Serviceが存在する限りは普遍の情報ですので、基本認証を使用してActionsを使用する場合、デプロイの度に認証情報が流出する危険性があります。
ちなみに、App Serviceでは基本認証そのものを禁止にしてしまう設定も可能です。
スロットに対する認証
App Serviceには「スロット」という機能があります。このスロットを使うとステージ環境や運用環境がすぐに作れるので便利です。なお、スロットを使用するにはStandardプラン以上のSkuが必要になります。
例えば、Githubのブランチでdevelopはstageスロット、mainは運用スロット、という場合に振り分けるケースもあるかと思います。
ユーザー割り当てIDを認証として選択した場合、スロット毎にサービスプリンシパルが作成されて「Webサイト共同作成者」権限が割り当てられます。スロットが違うと、別環境であるというイメージでいいかと思います。
先日、ステージ環境にデプロイしようとした際、Azure Loginのフローでエラーが出ました。自動生成されたworkflowsファイルに何も手を加えていないにも関わらず、デプロイが出来ないという事象がありました。
権限の確認をportalで確認したところ、運用スロットのサービスプリンシパルが継承という形でステージスロットに割り当てられてはいましたが、ステージスロットのサービスプリンシパルが割り当てられてはいませんでした。
該当のサービスプリンシパル自体は作成されていたので、「Webサイト共同作成者」をテストスロット環境下でサービスプリンシパルに割り当てたところ、無事にデプロイをすることが出来ました。
マネージドID関係でエラーが起こる場合、大抵この辺りの権限が適切に割り当てられていないか、割当先が違うかのどちらかなので、認証を使った操作をする場合は権限周りの注意が必要です。
